[antlr-interest] Repost: ANTLRworks: Why do these rules behave differently in the embedded interpreter?
david-sarah at jacaranda.org
Fri Jan 1 11:45:22 PST 2010
Jim Idle wrote:
> The interpreter is just a quick testing device and is easily fooled by grammar rules, use the debugger and not the interpreter and all will be fine.
Yes, but what Kyle pointed out seems like an obvious bug in the
interpreter in a case that it is supposed to be able to handle.
Either bugs like this should be fixed, or there is no point in having
the interpreter and all and it should be removed, with its functionality
being replaced by the debugger.
>> -----Original Message-----
>> From: antlr-interest-bounces at antlr.org [mailto:antlr-interest-
>> bounces at antlr.org] On Behalf Of Kyle Ferrio
>> Sent: Friday, January 01, 2010 11:11 AM
>> To: antlr-interest at antlr.org
>> Subject: [antlr-interest] Repost: ANTLRworks: Why do these rules behave
>> differently in the embedded interpreter?
>> That leaves us with the following rule, for which the interpreter runs
>> without error on our test input:
>> : multExpr ( ( '+' multExpr | '-' multExpr ) )*
>> [This is potentially ambiguous. Does a token bind more tightly to
>> another token, or to the binary operator '|' for alternatives? Yes,
>> we know the official ANTLR answer, but I'm questioning my
>> understanding of the specific implementation embodied in ANTLRworks.
>> See next rule.]
>> So I figured [maybe wrongly?] I was right about actions causing
>> problems. But wait. Let's dig deeper. This second rule
>> : multExpr ( ( '+' multExpr ) | ( '-' multExpr ) )*
>> works in the interpreter as expected for the first alternative (used
>> for 3+1) but produces a MisMatchedTokenException for the second
>> alternative (used for 3-1).
>> And better yet, this third rule
>> : multExpr ( ( ( '+' multExpr ) | ( '-' multExpr ) ) )*
>> works great in the interpreter for both 3+1 and 3-1, just like the
>> first rule does.
David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 292 bytes
Desc: OpenPGP digital signature
Url : http://www.antlr.org/pipermail/antlr-interest/attachments/20100101/3721e965/attachment.bin
More information about the antlr-interest