World: r3wp

unknown variable
? you need to use the %use-rule.r script:

http://www.rebol.org/view-script.r?script=use-rule.r

I guess, that you actually want to use just the STD function

I will adopt your script! Impressive. But i am still wondering if 
with the strategy in my script it would be possible to implement 
associativity properly?

well, if you modify it appropriately, why not?

except, that it requires some care, since all the operators you use 
are left-associative, except for the exponentiation operator, which 
is right-associative

>> std [3 ** 3 ** 3] translate
== [power 3 power 3 3]

>> std [3 * 3 * 3] translate
== [multiply multiply 3 3 3]

THat's why parsing reversal and taking care of ** specifically might 
be a good start...

Parsing reversal does not help IMO, because you have to process both 
left- and right-associativity at the same time

Notice, that my script parses left to right

I think I found a way... see you later today (or tomorraow). Again, 
many thanks for your feedback and congrat for your impressive script

It was actually so easy to fix: 5 'append to change into 'insert... 
I still have to check this does not break anything before posting 
a new version on rebol.org.

Ladislav... thank you again for pointing this bug!

Voilà... I renamed my script as parse-expression.r and it is on rebol.org 
... http://www.rebol.org/script-information.r?script-name=parse-expression.r

I just had to repace 5 'append into 'insert, so it fixing this big 
did not brak the "philosophy" of the implementation. Ouf :)

Example:
>> do parse-expression "-(-3+2)+3-2+3-sqrt((1+2)**2)-2**3+34"
== 28.0

@Endo: I tried exponent with ^, but as it is the escape character 
for rebol, i consistently end up with an error. If enyone can help 
on this! 

For the english comment, I promise I will take the time to translate 
the french comments soon.

Nice work Francois. Good conversation here too, with important details 
brought out by Ladislav.

Yes... Ladislav reminds me some basic math! God, I felt so stupid 
about this associativity bug! 

The reason why I developped parse-expression.r is because I need 
it to build an companion app for one of the best math book: Calculus 
3d edition from Smith & Minton! For now, I have developped a rebol 
library to transform any vid face into a function plotter, and parse-expression.r 
allows me to use human readable expression in the gui instead of 
guru rebol code :)

Ladislav:

How would you interpret x**-1/2 :
(1) [divide power x -1 2]
or 
(2) [power x divide -1 2]


A previous version of parse-expression.r returned (2)... but i considered 
this as a bug and changed it for (1) (see history 0.9.2 in the header 
of the script). But now, with our discussion on associativity, i 
am not sure anymore... 

Thanks for your help!

Precedence of ** is higher than /
The right form should be (1)

Thanks, this confirms my feeling

the associativity concern operators with same precedence.
** is right associative, the other ones are left associative

So, 2 ** 3 ** 4
is evaluated from rigth to left

like
2 ** (3 ** 4)

>> expr: parse-expression "2**3**4"
== [power 2.0 power 3.0 4.0]

It works :)

hehehe... It has been a long time since I had to implement such a 
challenging problem. It is so fun!

Must have something like yours somewhere, I used the stack approach 
though

like the HP48... I would like to see your stack approach. Should 
be interesting.

Lot of sources everywhere.
But I will look for it tomorrow.

I used this way
http://www.programmersheaven.com/2/Art_Expressions_p1

Thanks for the link. Seems like I did some kind of tree way...

>> std [1 ** - 2 / 3] translate
== [divide power 1 negate 2 3]

, i.e. you could as well "consult" the %evaluate.r script

A new version (0.9.5) of parse-expression.r is available on rebol.org 
(http://www.rebol.org/view-script.r?script=parse-expression.r). This 
fixes two bugs I found when writing the documentation, which is also 
available on rebol.org

Francois, don't forget to post update notices to the Announce group 
as well.

in R2 is there a single word which terminates all depths of parse 
rules?  I can't remember

hehe... I've been trying things for 15 minutes and just as I write 
this... I finally get it... hehehe   'END.

That triggers a backtrack to an alternate if there is one.

yeah... I just did a few tests, and it doesn't work in my case, which 
generates and endless rule   :-(

anything else?

I'm parsing code and I want to stop at any syntax error... right 
now I have no clue what to do!

END means end-of-input, not end-of-rule. If you really want to break 
out, try putting the parse call in a LOOP 1 and then BREAK in a paren, 
or in a function and RETURN or EXIT.

ah, loop 1 [] ... good idea   


I guess I can also force the end of the string... by using this old 
trick...
[here: (here: tail here) :here] 

though using break in a loop is much easier in my case.

thx for the tip... its odd  that I've never had to solve this case 
before , after all these years of parsing   :-)

If you want to fail to an alternate, you can assign the block [end 
skip] to a variable that would normally be set to none, and then 
make references to that variable whenever you want to trigger a failure 
condition.

yeah.. I've already done that one, that's what I usually need... 
but in this case, there is only one success and many failures... 
so its much more work to include the exit rule everywhere.

opt-fail: none

parse "abc" [some [["a" | "b" | (opt-fail: [end skip])] opt-fail]]

If there is only one success and many failures, you can make failure 
the default and set it to something non-failing in the success case. 
If you need to distinguish between failures, set a local variable 
with some distinguishing data. Remember, a predictable failure is 
just an unwanted success.

yeah but I still need to put opt-fail in all rules so its a burden 
I don't need, in fact its even going to slow down the parsing, so 
i'd rather just use a loop   :-)

loop 1 [    parse "abc"   [some [["a" | "b" |  (err-msg: "failed!" 
break)] ]]    ]

BREAK/return is your friend for distinguishing failures :)

Watch out when porting to R3 though, as PARSE itself is considered 
a loop there for BREAK in parens.

ah yes... forgot about that, even better.

in R3, does ( BREAK ) return the whole parse?