World: r3wp

Re. 'start - could use 'head for the same purpose, it's consistent 
too with the series accessors...

Other side of the coin, if 'end is a keyword, 'start is an intuitive 
companion.

HEAD would be a better name for a directive to reset the position 
to the beginning of the data. That behavior would be more consistent 
with the series accessors :)

'head?

Are you checking whether the position is at the beginning of the 
series?

Yep.

That's my interpretation of the 'start proposal.

It was an initialization proposal. Nonetheless, your HEAD? proposal 
sounds interesting. What problem are you solving that would need 
such a directive?

Hmmm... I don't see why it's *necessary*. It doesn't add any functionality 
- it just bulks up the parse dialect with an extra keyword.

At the beginning of the rule you are already at the head of the series, 
unless the data was already offset. Would you need HEAD? in the middle 
of the rule to determine if anything was matched already?

I was just commenting on word usage per the above examples...

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?