[antlr-interest] java.g in ANTLR v3

Terence Parr parrt at cs.usfca.edu
Wed Jun 28 10:48:56 PDT 2006


Ok, I'm looking at the java grammar submitted by Thomas as derived  
from the java language spec... when from what I can tell, in the  
addition of the generics causes all sorts of problems:

type
	:	Identifier (typeArguments)?
		(DOT Identifier (typeArguments)? )* (LBRACK RBRACK)*
	|	basicType
	;

Note that a<b can be the start of an expression or the start a type  
spec a<b>.  ANTLR correctly says

java.g:45:15: ANTLR could not analyze this decision in rule type;  
often this is because of recursive rule references visible from the  
left edge of alternatives.  ANTLR will re-analyze the decision with a  
fixed lookahead of k=1.  Consider using "options {k=1;}" for that  
decision and adding a syntactic predicate.
trying decision 3 again with k=1
java.g:45:15: Decision can match input such as "LT" using multiple  
alternatives: 1, 2

By looking at the grammar, I quickly realized the problem and added  
the option to force lookahead to k=1 for two reasons: there is no way  
to find lookahead beyond that to help resolve this  nondeterministism  
and ANTLR does the right thing anyway.  After running as follows:

type
	:	Identifier (options {k=1;}: typeArguments)?
		(DOT Identifier (options {k=1;}: typeArguments)? )* (LBRACK RBRACK)*
	|	basicType
	;

  I get the simpler:

java.g:45:15: Decision can match input such as "LT" using multiple  
alternatives: 1, 2

still, these errors are annoying. I have a plan to allow these errors  
to be turned off by specifying a magic cookie as provided by ANTLR;  
and it would give you a warning again if you change the lookahead  
decision.

For now, i am wondering if we could figure out way to prevent ANTLR  
from going crazy on these decisions. it tried to create a DFA for the  
FOLLOW(type), which is huge. :(  Hmm....

Ter



More information about the antlr-interest mailing list