World: r3wp

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.

Is it runtime adjustable, or does it need to be tweaked for the compile/build 
time?

As far as I know, it is not adjustable yet, but Carl may have plans 
to improve that...

some of you guys has to teach me what makes my code unreadable, otherwise 
there's no way i'll ever fix it...

will new parser enahncements help us to get better XML family support? 
:-)

I mean - we are not too strong with XML based stuff. Are new enhancements 
going to eventually simplify XML parsing? But maybe even R2 parser 
is good enough to have full XML support?

How can you simplify XML parsing?  What's simple about it?

As a mirror of the [n BREAK] proposal, i suggest the [n FAIL] proposal. 

This would let you FAIL from n nested loops. Otherwise, it would 
be to FAIL out of n nested blocks.

Then,


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

could be remplaced by:

[(p: 0) some [if (p < 0) 2 fail | #"(" (++ p) | #")" (-- p)]]

A little more readable ?

Since A84, AND is even more broken:

>> parse "abc" [and "a"]
** Script error: PARSE - syntax error in rule: op!
** Where: parse
** Near: parse "abc" [and "a"]

Steeve - no stuff, which uses recursion/nesting, will be ever better 
readable for user ...

From your example, it is not much obvisou, why you break/fail two 
levels? But - for more advanced parse gurus, n FAIL and n BREAK will 
surely be usefull ...

Ah, the above bug is not bug, I might know how it happened. I thought 
that we got STAY, and that AND is there too, albeit not working how 
we would like it to. But it seems that AND was just renamed to STAY, 
and so parser does not recognise AND keyword at all ...

pekr, parsing an xml file itself is quite easy.  


Actually, its converting and validating the xml schema or DTD which 
is complex because, basically you have to compile a new parse rule 
out of misaligned parsing concepts.  this will never be easier, until 
someone builds (and makes public) a simple to use, *complete* interpretation 
of each XML-based spec.  XML schema, xpath, etc.

I know it's an old topic, but have someone done a resolver for math 
expressions (parsing string input) ?
If not, it would be interesting to retry it with the new parse.

This (but it is not a pure-parse approach):
   http://www.rebol.org/view-script.r?script=calculese.r

huge, a was expecting something tiny

Another approach here:
  http://www.rebol.com/docs/core23/rebolcore-15.html

eheh, i was already reading that. A good start

re

    [...then none | break]

the "then none" part is unnecessary and can be safely omitted

generally, THEN can be omitted, if it is followed by a rule, that 
is known to succeed

one more note: in a rule like:

    any [... | break]


the "| break" part is totally unnecessary and can be safely removed

Something wrong with CHANGE.

that's OK:
>> parse s: "(1)" [change "(1)" "(22)"] ?? s
s: "(22)"

that's OK too:
>> parse s: "(1)" [change "(1)" "(2)"] ?? s
s: "(2)"

That's not OK:
>> parse s: "(1)" [change "(1)" "()"] ?? s
s: "())"


If the replacement string is shorter than the matched string, then 
it fails.
A bug i mean...

Bug posted

The result is imo OK

>> change s: "(1)" "()" s
== "())"

why ? 
i want to change "(1)" not only "(1"

we are in parse here

it's a change/part which is performed

simply put - you replace original string, right? You put new one 
into the string being replaced. If the new one is of the less length, 
then only such length is being replaced. If the new one is longer, 
then the string is shifted/extended.

But change/part just tells you, how many chars you replace, no? mmnt

>> change/part s: "(1)" "(2222222)"  4 s
== "(2222222)"

hmm ...

change must replace the complete matched rule, it has nothing to 
do with the quality (length) of the replacement data.
I'm sure it's a bug

then above R2 example is buggy too ...

/part -- Limits the amount to change to a given length or position.
         range -- (Type: number series port pair)

I thought that /part is there to allow us to set limit on number 
of chars being changed. Why in above case the original string got 
extended, when I limited it to 4 chars?

We are in PARSE here, it has nothing to do with the behavior of CHANGE 
in normal rebol code

Well, I might be confused as well ... not using 'change much ...

why do you repeat it? I try to point out, that it might share internal 
representation, and that might be buggy?