World: r3wp

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.

For those who think PARSE isn't tricky enough to use now, that would 
be great, Maxim.

i agree

still, I've never had problems in real-life data so far..., but I 
tend to build very wide & flat rules, instead of using recursive 
rules... I guess that's why.

It would avoid that i manage my own stack most of the time

any one done any metrics on actually parse depth limits?

re the tail-call optimization: some recursive rules, like e.g. the 
above correct-bracket rule are not tail-optimizable; OTOH, I already 
programmed a couple of algorithms, where I used my own stack to make 
sure it is as big as needed

Ladislav, counters would have to be combined with an explicit stack 
in the mixed bracket case.

As you already know, of course :)

It would be like run-length encoding your explicit stack.

I remember having requested 3 commands to speed up the management 
of  our own stack in the past [push, pop and rollback]

remark currently uses a stack and stores inner parsing explicitely, 
with offsets& stuff while flattening the inner-most tags first, this 
allows the whole engine to use a single flat 'ANY [ dozens | of | 
rules ].  it loads rebol dialect data within nested < > pairs in 
html ...  works well, but its pretty complex to setup.  would be 
nice to have something standard to code against.

something user types would be well suited for in R3  :-)

Yeah, I caught the "read-only access to the stack" request too. Useless 
for incremental parsing without being able to restore, basically 
parsing continuations. Which would require a ground-up rewrite of 
PARSE.

(if/when they will arrive)

Maxim, that sounds like something I do now without user types.

push and pop would be the default accessors for set and get.  index 
being the rollback.

That sounds like standard OOP. User types only map their operations 
to the action! functions.

Brian, if a special command allow to return the stack [a list of 
positionned blocks], it's not really difficult to perform the continuation, 
i don't need for a special mode to do that.

Assuming you can continue from the top level, I can see that. Continuing 
from further up the stack seems a little tricky to me though...

Assuming yo are using the PARSE stack and not rolling your own.

I wonder if a PARSE optimizer could be written, to reduce use of 
stack and other resources by automatically rewriting the rules.

rollback would be neet as a parse keyword  :-)  it would allow us 
to break several levels at once... something I would have needed 
when I did my XML schema validation engine.

brian, wait a few hours, Gabriele will pop up saying he has one, 
but unfinished and slightly buggy, somewhere on his HD   ;-D

Gabriele always has something like this. His stuff can be difficult 
for mere mortals like me to understand though :(

I swear, it seems like he writes his code using a literate encoding 
engine so that he can remember what it does. Write-only code.

Great code though :)

With R2

paren: [#"(" paren #")"]

can be replaced by the rule

p: 0
cont: none
start: [#"(" (p: p + 1)]

rule: [start any [
	start
	| #")" (cont: if zero? p: p - 1 ['break]) cont
]]

But i wonder if it's faster

Likely not. The question isn't faster, it's whether it runs at all.

i'm a little worried now, i'm afraid we can't bound our own words 
with commands in R3