World: r3wp

And it's finally break from a loop, rather than break from a block 
(supposedly).

is it just me or Carl is sidestepping the n BREAK proposal?

or BREAK/depth n  in case of a call within a loop.

(loop in a function, not parse)

Yes, that's unlikely to be implemented. He says it doesn't fit in 
with the rest. Same with n FAIL.

but its a hell of a powerfull addition to parse and to general code 
control.  I don't see why Carl can't see any use for it.

being able to drop from foreach [foreach [foreach [....]]] in one 
call is sooo usefull soo often.

That proposal was only for PARSE, not for function loops.

I know, but its as usefull within code.

within parse its a great optimisation for in-line parsing.

And you can do that with CATCH.

yep, and for functions, you still got THROW/CATCH and RETURN, which 
are enough to my mind.

n break allows you to tell the parser that you DON'T want any backtracking. 
 its a way to optimize rules for speed, if nothing else.

that's an optimization I agree, but all the proposals are the same, 
optimizations.

The BREAK, THROW, RETURN, EXIT, HALT and QUIT functions are implemented 
the same way, just with different error codes.

obviously n BREAK can be simulated using longer, non-recursive rules.

but n BREAK allows us to leverage smaller rules reuse, as if they 
where large complex rules and still benefit from the same speed of 
a root rule backtrack.

I think that Carl is trying to balance speed, ease of use, and debugability. 
In practice n BREAK would be tricky to debug, and doesn't actually 
reflect what PARSE does internally. Apparently PARSE isn't actually 
recursive descent - it just fakes it with a state machine.

yeah, maybe its just really hard to implement based on the parse 
algorythm... so not worth the time to implement.

Plus, it makes the code flow really tricky to understand. You aren't 
doing your later maintainer of your code any favors (even if it's 
you).

I am not sure why "to end" attempted several times does not fail? 
Simply put - if you put any rule, it consumes the input, so I would 
expect, that once at the end of th input = the rule was matches, 
second call of "to end" should fail, no? It does not correspond to 
"to "abc"", which called consecutively would try to find ANOTHER 
match for "abc", not just the same. I don't see a reason, why "to 
end" should have an exception. It should imo definitely cause termination.

Because you can't through the end, not even with THRU END. And once 
you reach the end, END always succeeds.

And TO "abc" will also continue to succeed, matching the same "abc" 
every time. THRU "abc" skips past the "abc" like you say.

you can't -> you can't go

Are parse enhancements over, or do we get some other?

Well, a89 isn't out yet (when last I checked). Beyond that, it depends 
on how Carl reacts to the recent blog on the parse plans.

So according to his doc, we should get BREAK/RETURN and DO?

We don't need BREAK/return anymore, but he can reuse the code he 
used to implement the RETURN paren operation. I hope we get DO, but 
Carl was iffy since few were puushing for it. Gabriele's been silent, 
which is weird since it was his idea.

Carl should not judge upon his own usage of some features ...

But generally - the level of feedback is lower and lower. We need 
to get R3 into beta with requested features in few months, as we 
are starting to loose ppl being interested ...

Um, yeah, but he should about OF (as ALL). What he wanted to do with 
OF was important.

The level of feedback? It's been a discussion. When it comes to PARSE, 
the discussion has pretty-much resolved itself.,

Yes, that one might be missed. Dunno why he wants to remove it. Also 
LIMIT would be nice to have ...

He is wary of adding it because he knows how difficult it would be 
to implement it. LIMIT too :(

well, otoh we lived without OF for so long. I think it can be done 
in a conventional (recent) way :-) I think that Carl should dedicate 
few more days to finish parse and move on to Extensions :-)

... because that is the way to release host code ...

The conventional way has exponential overhead.

All PARSE needs is a few final decisions. I expect that it won't 
be too difficult to do the rest, at least the rest that won't be 
put off.

The DO operation was proposed 5 years ago, before R3's change in 
the behavior of DO/next. The new DO/next is much better suited to 
the parse workarounds than the old DO/next was. We can thus do without 
the DO operation if need be.

The BREAK/return proposal was proposed before Carl added the RETURN 
paren option, which makes BREAK/return unnecessary.

OK, so we are almost done with parse, right?  (As I don't expect 
Carl changing his mind about the deferred proposals, at least not 
for 3.0)

The only still-missing proposals that aren't easy or efficient to 
work around are OF and REVERSE. They will be missed if not included. 
Unfortunately, the same reasons why they will be hard to work arond 
if missing, are the reasons why they would be difficult to implement 
:(

btw - what is the outcome of so called - complementing? Will we get 
it enhanced, so that we can use it even with Unicode? I noticed Carl 
said that complements could be enhanced ....

I expect that PARSE release features will be done in a89 - the rest 
will be bug fixes.

One of the bitset! bugs was fixed in a88, but complementing is yet 
to come. It will probably be the using a bit for a flag method.

Shouldn't be such enhancement part of the proposal doc? (just in 
order to have it documented :-)

Yes, it should. Care to add it?

I can add it, just not sure I would describe it precisely :-)

Carl asks about the usability of Until proposal - if not answered/defined, 
it will not be part of 3.0 -  http://www.rebol.net/r3blogs/0271.html

Did an initial answer, but Ladislav really needs to expand on it.