World: r3wp

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

such trick:
(cont: if zero? p: p - 1 ['break]) cont
doesn't work anymore IIRC

try without the '

i guess not, but i will try

it doesn't work

it's a broblem specificaly for the BREAK command, because it can't 
be encaped in a block, it has to be on the same level than the ANY/SOME 
block to be effective

yeah, cause it just breaks the block its in.

but with the IF command it should not be too much worrying

some rules will definitely need to be changed with the three hacks 
he now made officially "illegal"

but that should only affect.... hackers...  ;-)

; R3 style
rule: [(p: 0) any [
    #"(" (++ p) |
    #")" if (1 >= -- p) then break | none
] if (p = 0)]

On one line:

rule: [(p: 0) any [#"(" (++ p) | #")" if (1 >= -- p) then break | 
none] if (p = 0)]

As i thought, we are saved :-)

Needs some tweaking though.

the   [IF () THEN rule | rule ]  reads nicely when used in parse 
rules. I find.

a smell of old BASIC

hehe  yeah... that's it  ;-)

what's that if (p=0) at the tail ?

Checks to see if the counter is even. Badly, I'm afraid, needs tweaking 
(which I'm doing now).

why not use  'EVEN?

EVEN? you mean negative ?

it can't be...

Even, meaning the ( and ) are balanced. p starts as 0, and should 
end as 0.