World: r3wp

It isn't needed. It's basically the same as if the paren was included 
on its own, but not in the alternation.

That's what I thought. But Peter must have thought it was useful 
for something.

Here's a working version of that example:
parse [1 2 3 4] [
	(acc: 0)
	any [set inc integer! (acc: acc + inc)]
]

I thought maybe the start code is only done when one of the other 
alternates is (about to be) matched.

Perhaps he thought a paren could only follow a rule.

We should wait for Peter's input on that.

I like the RETURN proposal as this:

	RETURN rule


Match the rule and return a copy of the value from the PARSE function. 
Like COPY then BREAK, but without the temporary variable.

BrianH: I posted link to Ladislav's Core proposals. There's parse 
section in there too. You can look at r3-alpha parse group .....

Theye are already covered by the existing proposals.

I vaguely remember suggesting PARSE dialect be extended into parens 
with a few commands. Parens are executed as normal rebol dialect 
(not parse dialected in any way). If I remember correctly, it was 
thought better to keep the parens 'pure' rebol. If that is to be 
maintained, then I think Peter's RETURN command ought to be morphed 
into a parse command, as you suggest above, Brian.

-- ie. that's a good idea.

PARSE actually calls DO for those blocks.

blocks -> parens

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?