[antlr-interest] Two More Bugs in ANTLRv4 + A new one, again ; )

Jan Finis finis at in.tum.de
Mon Feb 27 12:40:36 PST 2012


Hi Ter,

thanks for the answer. The expr rules I presented as examples were only 
for showing the bug, they are not intended to be meaningful expression 
definitions (however, the concatenation of two expression is often a 
meaningful operation, for example when specifying a grammar to match 
regular expressions).

I see that a concatenation like

expr : expr expr;

might be a problem since it is somehow "doubly" left recursive, however, 
then the error message is misleading. The word "mutually" somehow 
indicates at least two rules. Another thing I wonder about is why the 
rule parses fine (and even the resulting parser matches those 
concatenations correctly) with the earlier 4.0ea version I have. It was 
somehow possible there. Seems that Honey Badger is full of magic ;). 
Would be really nice if you could make that one work, somehow.

The next thing (sorry for digging out new stuff all the time ;) I 
encountered, probably a feature, but, in my oppinion, an annoying one:

When using non-terminals in actions, ANTLR forces me to use the member 
access operator, e.g.:

expr returns [int i]
   : '+' e=expr { $i = $e.i; } // Works fine
   ;

stmt
   : (l=label ':')? expr ';' { if($l != null) { 
System.out.println("Label was there!"); } //Does not work, missing 
member access at $l

As you see in the second example, I want to use if($l != null) to test 
whether the optional part (a label) was present in the input. However, 
ANTLR complains that I must use a member access with $l, which is in 
this case not what I want. So why is there the need to use a member 
access? Sometimes the user really wants to refer to the context, not one 
of its members.

Regards,
Jan


More information about the antlr-interest mailing list