World: r3wp

Forget my last remark, a binary can't contain #"^}" but a multi string 
yes

Peter, Steeve, the original problem that started the parse proposals 
was the problem of complimenting charsets. However, it quickly changed 
to improving PARSE in general. Then, while we were waiting for the 
parse proposals to come up on the todo list, we came up with a better 
solution to complimenting charsets, which is not yet implemented 
and which is not limited to PARSE.

Or maybe it's complementing? How would you compliment a charset? 
Say it has good coverage?

BrainH: what is the method to get complementing like feature back? 
I havent seen anything discussed in that manner yet ...

Using a bit in the charset that would mark it as "complemented", 
and then all of its matching algorithms would do an internal not.

The discussion was primarily in the comments of the relevant tickets 
in CureCode, though there was some in R3 chat. Not recently.

If parse was already rewritten from the ground-up, couldn't it be 
directly adapted to allow streamed parsing? :-) You said it could 
be added later, when rewrite happens, so ...

Yeah, but by "later" I meant after 3.0 comes out. I haven't even 
discussed with Carl what would be involved yet.

ok

I want to write more port code first and refine the model based on 
what I learn.

Plus, Carl's rewrite didn't change the basic algorithm of PARSE, 
just some details. I don't yet know whether my port PARSE is that 
easy.

even with a complement bit, if you use a few chained union's & complements, 
etc, you'll eventually need to bake it... in the end, all the complement 
bit is usefull for is to keep the charset to below half the maximum 
size of the complete encoding.

(which is still pretty big AFAICT)

Behavior of BREAK, ANY and SOME decided, finally: http://www.rebol.net/r3blogs/0270.html

Yesssss, the return of BREAK !!!!

i definitly  didn't love the previous way to exit from a loop

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 :(