[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