World: r3wp

as shown above, it is superfluous; the a: [b fail |] rule is exactly 
as simple as a: [stay b]

All of the new additions are superfluous, Ladislav. They were added 
to make our lives easier, not to enable stuff we couldn't do before.

I'm  looking at this.....    a: [b fail |]  and its totally obscure 
... I don't see it at all, I can study and eventually "understand" 
it, but within a 1000 line parse rule... <eek>. 

the way I see STAY is: [pos: b :pos]

(speaking as a general user... not myself specifically)

Sorry, that's still AND. STAY is [pos: opt b :pos].

well, I do not think, that e.g. NOT is superfluous, since it substantially 
simplifies the expression. This is not true for STAY.

The fact is that all of these were added to make our lives easier. 
Now I don't think STAY is worth the effort to implement it, but given 
that Carl *already has* implemented it, it it worth removing? This 
is regardless of the merits of AND, which are unquestioned.

NOT is very important, especially because charset can't be complemented 
in R3 (Actually they can, but it's a monstrous thing to add all the 
possible chars in a bitset, just to skip someones)

I agree that if we were to dump all of the enhancements but one, 
NOT is the one I would choose :)

We could fix charsets too (add a complemented bit), and that would 
help too.

would be useful for FIND

unless Carl implements the find/not refinement

I agree that if we were to dump all of the enhancements but one, 
NOT is the one I would choose :)
 - I guess, that it is my favourite too

Carl *suggested* the find/not option :)

'NOT  and the 'TO/'THRU multi.  its just soooo much simpler to slice 
and dice text using it, which is a large percentage of what parse 
is used for.


I remember Carl's historical reason that it made us lazy... hehehe... 
his CR.LF stripping example shows that he is quite lazy himself  
;-)

TO/THRU multi is not so important in text parsing because we can 
use charsets

I am just curious, whether Carl intends to implement the full TO/THRU, 
acting on any subrule

it's working now in a84

It is badluck, that recursive rules are not useful in fact, since 
the stack is too small :-(

There are likely to be limits. I'm a bit shocked that he was able 
to push it as far as he did :)

steeve, it is... you don't have to build a grammar, just find a set 
of words...

I also remember that Carl feared it would lead to people building 
RE-like slow parsers.

full TO/THRU is not implemented yet, trust me

If you say so, Ladislav, then I look forward to what is to come :)

working here

>> parse "abcd" [any [to ["c" | "b"] ?? skip]]
skip: "bcd"
skip: "cd"
== false

what do you mean by "full" implemented ?

well, but I do not know if Carl intends to implement the full TO/THRU, 
as I said...

what do I mean? the "full"

    a: [thru b]

can be defined as a "shorcut" for

    a: [b | skip a]


you can try, that this works for any rule B as far as you don't need 
to use too deep a recursion. As opposed to that, the THRU keyword 
does not accept any rule B, as documented in Carl''s blog

Right. I would just be happy if he adds the not modifier, but the 
current capabilities are moree than I was expecting.

actually, to/thru multi, is like an ANY with an embedded skip... 
I don't think there is any slowness related to it.
coudn't thru be implemented this way?

skip-rule: [skip]

thru:   [any [ ["c" (skip-rule: [fail]) |  "b" (skip-rule: [fail])] 
skip-rule]]

but the A: [b | skip A] is weird, i never do that to avoid the stack 
limit error.
this instead:
a: [
    any [
       b break
       | skip
    ]
]

the above has the advantage of not requiring stack.

you don't know break Maxim ;-)

Yes, Steeve, I used it just the recursive expression just for demonstration 
purposes (recursion can be even used to demonstrate how ANY works). 
OTOH, it is a problem to e.g. define a non-recursive rule to detect 
correctly parenthesized string containing just #"(" and #")"

So, another problem of Parse is, that recursion does not work as 
well as it should :-(

(or, as well as may be needed)

Do you mean the USE proposal, or does it suck in other ways?

just this: correct-paren: [any [#"(" correct-paren #")"]] - you can 
use it to parse strings, but just "short ones"

or, rather, just the "shallow ones"

Ah yes. For long ones you need a counter in a production.

Which can be checked with IF (condition) now :)

hmm, counter does not help you in case like:


correct-bracket: [any [#"(" correct-bracket #")" | #"[" correct-bracket 
#"]"]]

what is the problem with correct-paren:  ?  you mean it can't go 
beyond  n recursions?  or is it something else?

Not by itself it doesn't. It does kinda make things tricky that recursion 
is implemented with recursion.

Rather than with CPS or tables.

yes, Max, the problem is, that the rule does not work when applied 
to deep recursive data

ok, well that is a general problem of parse, (and of REBOL in general, 
I might add).

Yup, recursion is bounded and not tail-call optimized :(

it would be nice to be able to have control over the interpreter 
stack...

well, i must say i never have such problems, i use rules adapted 
to incremental parsing to avoid too deep recursions.