World: r3wp
[Parse] Discussion of PARSE dialect
older newer | first last |
Steeve 15-Mar-2011 [5535] | Precedence of ** is higher than / The right form should be (1) |
Geocaching 15-Mar-2011 [5536] | Thanks, this confirms my feeling |
Steeve 15-Mar-2011 [5537x3] | 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) | |
Geocaching 15-Mar-2011 [5540x2] | >> 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! | |
Steeve 15-Mar-2011 [5542] | Must have something like yours somewhere, I used the stack approach though |
Geocaching 15-Mar-2011 [5543] | like the HP48... I would like to see your stack approach. Should be interesting. |
Steeve 15-Mar-2011 [5544x2] | Lot of sources everywhere. But I will look for it tomorrow. |
I used this way http://www.programmersheaven.com/2/Art_Expressions_p1 | |
Geocaching 15-Mar-2011 [5546] | Thanks for the link. Seems like I did some kind of tree way... |
Ladislav 15-Mar-2011 [5547x2] | >> std [1 ** - 2 / 3] translate == [divide power 1 negate 2 3] |
, i.e. you could as well "consult" the %evaluate.r script | |
Geocaching 16-Mar-2011 [5549] | 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 |
Gregg 16-Mar-2011 [5550] | Francois, don't forget to post update notices to the Announce group as well. |
Maxim 19-Apr-2011 [5551x2] | 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. | |
BrianH 19-Apr-2011 [5553] | That triggers a backtrack to an alternate if there is one. |
Maxim 19-Apr-2011 [5554x3] | 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! | |
BrianH 19-Apr-2011 [5557] | 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. |
Maxim 19-Apr-2011 [5558x2] | 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 :-) | |
BrianH 19-Apr-2011 [5560] | 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. |
Maxim 19-Apr-2011 [5561] | 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. |
BrianH 19-Apr-2011 [5562x2] | 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. | |
Maxim 19-Apr-2011 [5564] | 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)] ]] ] |
BrianH 19-Apr-2011 [5565x2] | 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. | |
Maxim 19-Apr-2011 [5567x2] | ah yes... forgot about that, even better. |
in R3, does ( BREAK ) return the whole parse? | |
BrianH 19-Apr-2011 [5569] | (BREAK) breaks out of the whole parse, as does RETURN; BREAK breaks out of an interation, which all enclosing rules are, so it will break out of any block, not just ANY, SOME and WHILE blocks. |
onetom 26-Apr-2011 [5570] | what's the best practice for recognizing words with certain syntax? (besides using the various word variants) i was thinking about using the datatype notation or similar pre-/postfix characters |
Geomol 26-Apr-2011 [5571x3] | Can you give us examples of these words, you want to get recognized by parse? Then it may be easier to give opinions. |
If you mean things like "word!", then this is a way: alfa: charset [#"a" - #"z" #"A" - #"Z"] numeric: charset [#"0" - #"9"] alfa-numeric: union alfa numeric parse "word!" [copy word [some alfa any alfa-numeric "!"] (probe word)] | |
Will also parse "word2!, but not "1word!". | |
onetom 26-Apr-2011 [5574x2] | i was not talking about matching string input. that's obvious |
parse [some word! other* stuff'] | |
Geomol 26-Apr-2011 [5576] | I'm not sure, I understand, but maybe you mean something like: >> parse [a few words of type word! "string" 1] [some word! string! integer!] == true Else it would be easier with an actual example. |
onetom 26-Apr-2011 [5577x3] | this was an actual example. i can match it with [some word!] but i would like to differentiate between the words based on what is their last character |
i know it's suboptimal, just wondering if still possible somehow to reject a matching rule later somehow | |
parse [xxx*] [set w word! (unless #"*" = last to-string w [doesnt-match])] | |
Geomol 26-Apr-2011 [5580x2] | Ah ok, then you need to convert the word to a series, for example a string, and check on last letter: parse [some word! other* stuff'] [some [set word word! (print last form word)]] |
It's tricky to reject a rule later, and PARSE has changed over time, so I'm not sure. | |
onetom 26-Apr-2011 [5582] | ok, this is how i imagine a solution would look like: >> parse [normal-word word-with-star*] [word! starred-word!] == true |
Geomol 26-Apr-2011 [5583] | I would use string parsing in this case. |
onetom 26-Apr-2011 [5584] | i would rather use a separate word as a modifier then. makes things a lot simpler. maybe i would do a pre-processing 1st to break up these words into separate ones |
older newer | first last |