World: r3wp

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?

ah, it might be good. I don't know ...

in parse, CHANGE is a shortcut for REMOVE INSERT.

>> parse s: "(1)" [change "(1)" "()"] ?? s
s: "())"

Should give the same result than:

>> parse s: "(1)" [remove "(1)" insert "()"] ?? s
s: "()"

It clearly behaves as 'change func ...

I have a headache to find out, how 'change behaves in REBOL itself. 
Now if the parse version is supposed to behave even differently, 
then I am completly lost without the trial and error aproach in console, 
and it totally sucks ...

it's not behaving the same way, if it was the same, we would not 
have this difference:

>> parse s: "(1)." [change "(1)" "(11)"] ?? s
s: "(11)."

>> head change "(1)." "(11)"
== "(11)"

In parse it's a change/part that is performed

And as such, is correct, no?

>> head change/part "(1)." "(11)" 3
== "(11)."

yep a change/part not a simple change

damned, altme playing on my nerves ... another message lost ....

You are right, it is most probably a bug:

>> head change/part "(1)" "()" 3
== "()"

>> parse s: "(1)" [change "(1)" "()"] s
== "())"

Ladislav, you are right, the revised rule passes my tests: [(p: 0) 
any [#"(" (++ p) | #")" if (1 <= -- p)] if (p = 0)]

Actually, Steeve, the behavior of parse's change does have to do 
with the behavior of change in normal code. That would be an error 
if the CHANGE/part function had that same behavior. It's a bug.

i don't understand what you mean, anyway change in parse has a bug 
:-)

What a mess...

digit: charset "0123456789"
num: [some digit opt [#"." any digit]] 
term: [num | #"(" any lv1 term #")" | #"-" any lv3 term]
calc: [(expr: do expr) stay insert expr (probe e)]
lv4: [
	remove [copy expr [term change #"%" " // " term]] calc
]
lv3: [
	any lv4 
	remove [copy expr [term change #"^^" " ** "any lv4 term]] calc
]
lv2: [
	any lv3 
	remove [copy expr [term change #"*" " * " any lv3 term]] calc
	| remove [copy expr [term change #"/" " / " any lv3 term]] calc
]
lv1: [
	any lv2 
	remove [copy expr [term change #"+" " + " any lv2 term]] calc
	| remove [copy expr [term change #"-" " - " any lv2 term]] calc
]

>> parse probe e: "2+3*2-(-2^^4/6)/2" [some lv1]

2+3*2-(-2^^4/6)/2
2 + 6-(-2^^4/6)/2
8-(-2^^4/6)/2
8 - (-16.0/6)/2
8 - (-2.66666666666667)/2
8 - -1.33333333333334
9.33333333333334


I think i can make that more clean if only the commands AND, CHANGE 
(bugged)  was available.

steeve nice way to make a quick and fun use of parse ...
I never thought about it

steeeve example should be teached to kids in any schools :P hihihihihihi

i like this example it's short and has many of the parse  features. 
Even if I'm not able to precisely understand how it works i can sense 
globaly that he inserted in his main rule 4 depth parsing level using 
sub rules. He stores sub result of each depth. Each depth is then 
computed and it's result it's passed to the upper level. that's nice 
really ...

Steeve - you used STAY, which is gonna be removed :-) At least Carl 
said so on R3 Chat, it is also as well reflected in updated Parse 
proposal document ...

INTO is marked as being implemented too ... nice ....