World: r3wp

but now, the  (1 <= -- p) condition is false i mean

[(p: 0) some [#"(" (++ p) | #")" if (1 <= -- p) then none | break] 
if (p = 0)]

Handles the empty string. Given the | break alternate, ANY and SOME 
are equivalent.

Yours would work, but wouldn't recognize an empty string.

still, aren't the condition (1 <= -- p) wrong ?

-- decrements but returns previous value

You want the condition to be false, so the break is chosen.

if p = 1 then it must break

No, you want to break when p is 0 or less.

Even in your version.

wait...

The | break is not only the else for the if (), it is also the alternate 
chosen if #"(" or #")" are not matched.

That is what THEN gives us: the ability to overload alternates.

oh ok, it's not exiting the loop for such case [()()()()]

Right :)

Am ok now

But we *want* to exit the loop in this case: ")("

yep

I find myself liking THEN quite a bit :)

But we still have a problem with break not being able encapable in 
a block.
We can't construct reusable rules with such logic.

i mean we can't push the part [if (1 <= -- p) then none | break] 
in a separated rule

we need a parameter for break

It's tricky, true. There was either a proposal or a bug report to 
make BREAK break out of the closest enclosing ANY or SOME...

break level

break 0

break -1

Counted back, not negative.

if you prefer

time for a new proposal Brian

'ROLLBACK anyone  ;-)

Done, as n BREAK :)

funny I suggested it 2 hours ago, and you guys end up with a path 
with a use case implementing a simple rule  :-)

I had to figure out how to make it fit in. Done. Off to dinner.

guys, what have you created for the simple recursive replacement 
of paren: [#"(" paren #")"] looks like regexp hell in comparison 
...

Not having proper recursion support is big downside of REBOL.

>> parse d: "abc" [change skip 123]
>> d
== "123bc"

Isn't it weird? I would expect a123

hmm, maybe it is correct, just need a bit more of thought. Skip is 
not skipping "a", it is "matching" "a", hence defining, what should 
be replaced ...

The stack limit is so lame, almost unusable:

REBOL level recursion:

>> cnt: 0 recursion: does [++ cnt recursion] recursion
** Internal error: stack overflow

>> cnt
== 4004

Parse level recursion:

>> cnt: 0 rule: [(++ cnt) rule] parse "123" [some rule]
** Internal error: internal limit reached: parse

>> cnt
== 512

I never bumped into the stack limit in R2 with parse. Is it smaller 
in R3?

will try ...

no, it is exactly the same ...

But function example gives me == 14265 .... so - is function recursion 
stack lower in R3?

I think it varies with the OS platform used. I get 1335 in OSX.

sounds plenty for parse

Graham: your "plenty" and my "plenty" are not the same, as it looks 
;-)

But can it be controlled? I figured this is something controlled 
by the OS.

Pekr: the original rule was a little bit more complicated: paren: 
[any [#"(" paren #")"]], but still much simpler, than the above hell. 
Which is nothing compared to a trial to do the same in the case of:

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

Ladislav - your recursive example reads so cleanly, whereas flat 
variant starts to remind us of regexp :-) Well, it is kinda still 
nice, that with flat variant stuff like that is possible, but that 
should not be used as an excuse, that REBOL non ability to properly 
recurse sucks ...

but - the topic is probably more deep, because if it would be easy 
to make rebol tail recursive, it would already happen, no?

The fact is, that this has nothing to do with tail recursivity: neither 
of PAREN or BRACKET is tail-recursive. The only problem is, that 
the stack depth does not look sufficient to use recursive rules for 
moderately complicated cases.