World: r3wp

Right - so doing an extra bind may slow things down.

More importantly it will override the meaning of the RETURN function 
at a point where you would expect it to work.

Clearly my proposal for START is based on my ignorance and inability 
to search the documents properly :-)

It wouldn't hurt as a form of slef-documenting code, though.

Actually, I think it would hurt (no offence). The word start is a 
common name for parse rules and every keyword we add can't be used 
as a parse rule name. Something to consider when making proposals.

Gabriele's DO command is interesting.

I wonder why it could not become more "functional" and be used after 
the SET command, eg:
	SET result DO integer!

That DO proposal was the first one to be rejected. It will take some 
serious problems with dialecting to get it included.

Perhaps, Peter, you could post a withdrawl for START on the blog.

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 ?