Hi Jonathan,
I also assumed there should be nothing particular with '<=', '==' and
'>='. So I changed the order: the '<=', '>=' and '==' first and then the
other two ones as you advised, and my problem was solved.
By the way it has been a long time ago when I did the course
'Constructing Compilers and Interpreters' and I read Alfred Aho, Ravei
Seth and Jeffrrey Ulman's book about compilers. Anyhow, now I am retired
but still love to do software engineering.
Many thanks,
Thiel
Op 18-4-2011 15:17, Jonathan Rochkind schreef:
> There's nothing special about "<=" and ">=", but you've left out the part of
> your grammar that probably matters.
>
> Parslet will evaluate alternatives in a rule in the order they are given,
> matching the first one that matches. Consider:
>
> ...
> rule :operator { gt_op | ge_op }
> ...
>
> parse(">=")
>
> First it will try to match gt_op, and say, yeah, that first character matches
> gt_op, great. Then it will go on to try to match the next character, "=",
> according to whatever other rules are present in the grammar, either matching
> it to something else or failing to parse.
>
> If you instead put ge_op first in that rule, then first it will try to match
> the whole ">=", and consume both characters, and only then go on. Only if
> ge_op fails to match, will it go on to the next alternative, gt_op, and then
> match a ">" which is not followed by an "=".
>
> So in your case, changing the order you list alternatives to have the
> 'longer' one first may work. But in general, this manner of parsing, where
> alternatives are tested in the order given and the first one that matches is
> 'consumed'.... is fundamental to the way a PEG works, and wrapping your head
> around it is neccesary to write a grammar that does what you want.
> ________________________________________
> From: [email protected] [[email protected]] on behalf of
> Thiel Chang [[email protected]]
> Sent: Monday, April 18, 2011 6:49 AM
> To: [email protected]
> Subject: [ruby.parslet] Problem with parsing a relational operator
>
> Hi guys,
>
> I am testing to parse relational expressions and defined the following
> relational operators:
>
> rule(:gt_op) { str('>')>> space? }
> rule(:ge_op) { str('<=')>> space? }
> rule(:lt_op) { str('<')>> space? }
> rule(:le_op) { str('<=')>> space? }
> rule(:eq_op) { str('==')>> space? }
>
>
> To test them I used the following parse statements:
>
> Parser.new.rel_operation.parse_with_debug(' ( a - b )< c ')
> => Parsing succeds
>
> Parser.new.rel_operation.parse_with_debug(' ( a + b )> c ')
> => Parsing succeeds
>
> Parser.new.rel_operation.parse_with_debug(' ( a + b ) == c' )
> => Parsing succeeds
>
> Parser.new.rel_operation.parse_with_debug(' ( a + b )>= c' )
> => Parsing does NOT succeeds
>
> Parser.new.rel_operation.parse_with_debug(' ( a + b )<= c' )
> => Parsing does NOT succeeds
>
> Because of the parsing failures of the '>=' and '<=' operators I
> replaced the relational operator '>=' with ':=' just to know if Parslet
> could parse those two tokens as a relational operator.
>
> Parser.new.rel_operation.parse_with_debug(' ( a + b ) := c' )
> => Parsing DOES succeeds!
>
> Can anyone explain why parsing with e.g. '==', '<','>' and ':=' went
> well and '>=' and '<=' does not.
>
> Is there an 'undocumented' feature ;-) in Parslet which does not
> allow using '>=' and '<=' as symbols in Parslet or did I made a mistake?
>
> Thanks in advance,
>
> Thiel
>
>
>
>
>
>
>
