This is the first of a series of some ambiguities and improvements that I'm finding with the newest version of trparse with the --ambig option to display ambiguous parses.
1) The rule typeName is incorrect. It should have referenced packageOrTypeName, not packageName.
1) Although Antlr does a great job and rewriting left-recursion into kleene operators before running Thompson's Construction, it does not rewrite right recursion. Right recursion should not be used because it's inefficient because it causes a call to a sub-automaton in AdaptivePredict(). E.g., the NFA for packageName is:
1) For input with a method call System.out.println("s.x=" + s.x);, we have ambiguity on where to include .out. Should it be as a packageName or typeIdentifier?
We don't have a symbol table for the grammar to distinguish packages vs. types. Just get rid of packageName and typeName and just define a dotIdChain: identifier ('.' identifier)*;.
This is the first of a series of some ambiguities and improvements that I'm finding with the newest version of trparse with the
--ambig
option to display ambiguous parses.Input: in.txt
Ambig trees:
typeName/packageName/packageOrTypeName
From the JLS20,
Notes
1) The rule
typeName
is incorrect. It should have referencedpackageOrTypeName
, notpackageName
. 1) Although Antlr does a great job and rewriting left-recursion into kleene operators before running Thompson's Construction, it does not rewrite right recursion. Right recursion should not be used because it's inefficient because it causes a call to a sub-automaton in AdaptivePredict(). E.g., the NFA forpackageName
is: 1) For input with a method callSystem.out.println("s.x=" + s.x);
, we have ambiguity on where to include.out
. Should it be as apackageName
ortypeIdentifier
?We don't have a symbol table for the grammar to distinguish packages vs. types. Just get rid of packageName and typeName and just define a
dotIdChain: identifier ('.' identifier)*;
.