World: r3wp

Anton - but there is some point in time we should start to make rebol 
bigger by adding unnecessary things, or we will never reach 100MB 
executable size and outer world migt not consider us being a rellevant 
alternative :-)

I don't think this is quite one of those situations, Petr :)

Unless we used looong words : )

One NOP keyword at a time :)

do what Carl does ........... and use one letter variables

Didn't you get Carl's simplicity blog? It was posted on Reddit and 
PLNews :)

can you use unicode for variable names?  I guess so ...

allows for me one letter variables available

Yes, you will be able to use Unicode for variable names. I wouldn't 
suggest it though: You have to use Character Map to enter half of 
Perl 6's operators because they did exactly what you suggested :(

Must be Carl's driving force to implement unicode

I think Anton is correct about Return...the Return should preceed 
the bracket: eg
 

end return ("the return value") is mch better than end (return "the 
return value").

I just followed Brian on that.

I was thinking that you not even have the parens at all, and just 
have RETURN rule.

ie. return [ rule ... ]

That way you could do this to return the first HTML tag from data:
	[to "<" return thru ">"]

So that would replace 'true?

Yup.

In particular, it would return a copy, like the COPY directive, not 
the SET directive.

Like!  Would that work for values? -- [to "<" copy a thru ">" "<" 
return a] ; - returns a if there is a < next?

What would you do when you need to process the data a bit first ?

eg. You return tags from different places in a rule, and to distinguish 
them you need to also return something extra, by prepending a code 
to the beginning, for example.

That's what code in parens is for. The USE directive will make that 
safer.

I don't think that returning values would really work because named 
rules are values.

Yes, you're right. Can be achieved with parens, of course.

Looking forward to using USE.

Carl was kinda weirded out by the modifying operations, but I pointed 
out that people do this anyway and get it wrong a lot.

Really ? They look so useful !

They do, but he was weirded out by the idea of PARSE modifying its 
data in place. Apparently he doesn't do that :)

(We can live without them, though.)

What's wrong with that ? Isn't that what RNA does ?

They're going in. If we were just doing what Carl wants, he wouldn't 
need to ask for suggestions and ask me to compile them.

(I mean enzymes that process RNA..)

You mean, Carl has already accepted them ?

Everything in that Parse Proposals page has already been discussed 
with Carl and could go in, barring insurmountable problems with implementation. 
I stopped putting stuff in when he stopped working for the day. There 
will likely be a couple going in tonight, but Carl is actively involved 
in this process.

Well, that sounds all good.

We've already made some changes based on these discussions, which 
is why there are differences from the REPs.

It was freeing when Carl said that we could use modifier keywords 
like ONLY for CHANGE and INSERT. I look forward to seeing how that 
would affect the INTO-STRING proposal :)

The main thing that Carl is concerned about now is that some of the 
proposals make use of the value calculated in a paren on occasion. 
I don't know why this would be a problem, but I'm sure it will be 
worked out or around.

Using 'remove -- a) removing a bracket only at the end of a string 
(as per Graham's example):

	parse "[this]" [remove "[" to "]" remove ["]" end]]

b) where you go down a false path:

	parse "abcdef123" [remove "abc" "123" | remove "abcd" "ef123"]

Would a) work?  Would b) reset the string as the first rule didn't 
match?

a) would work.

b) would not likely reset the string, just like code blocks don't 
undo.

You might be able to do b) like this:

 parse "abcdef123" [use [a] [remove ["abc" a: "123" :a] | remove ["abcd" 
 a: "ef123" :a] to end]]
or like this:

 parse "abcdef123" [use [a] [remove ["abc" a: "123" :a | "abcd" a: 
 "ef123" :a] to end]]

The standard method of putting the longest match first will still 
be the best.

Ooo, I just figured out another possibility for b):

 parse "abcdef123" [to "123" reverse remove ["abc" end] | to "ef123" 
 reverse remove ["abcd" end]]

parse "[this]" [remove "[" to end reverse remove ["]"]]

In reverse, the end is the beginning :)

And the beginning is the end :)

Shorter with tail, perhaps?

parse "[this]" [remove "[" tail reverse remove "]"]

How about this?

	parse "abc" ["a" to end reverse "bc"]

Is there anything that can be done to assist block parsing?

Yup, that would work.