[antlr-interest] syntax predicate strange behavior

Ilia Kantor ilia at obnovlenie.ru
Tue May 1 01:28:54 PDT 2007


> > command_user_body:	
> > 	 (LCURL) => LCURL command_arguments? RCURL -> ^(USER_COMMAND command_arguments?) |		 			
> > 	 -> USER_COMMAND
> > ;
> > 
> > On input LCURL WS WORD WS MINUS GT...
> > this gives me exception from DFA.noViableAlt at first WORD token.
> 
> Which decision is it trying to predict when it fails?  That rule has a
> '|' decision and a '?' decision.  

DFA.predict call in command_user_body is first call in most outer try { .. }.

     try {
            // GetScopeValueClean.g:248:4: ( ( LCURL )=> LCURL ( command_arguments )? RCURL -> ^( USER_COMMAND ( command_arguments )? ) | -> USER_COMMAND )
            int alt19=2;
            alt19 = dfa19.predict(input);

I believe, it indeed looks for | decision.
But second alternative is not taken on this input.

> The command_arguments rule might be 
> significant to understanding the problem.

command_arguments:	
	command_argument (SEMI command_argument)*;

command_argument  :
        (WS? WORD WS? MINUS GT) => WS? WORD WS? MINUS GT e=exprs_no_semi |
        exprs_no_semi ;


With backtracking it accepts first alternative, it should do same with DFA I guess, but it bails with DFA.NoViableAlt.

> Also, why the predicate on LCURL?  Probably makes sense in the wider
> grammar, but we can't see that ;)
Well, if user has first { in command body means the arguments must follow, 
otherwize it is just bare command.

 
> 
> > By the way, this works fine:
> > 
> > command_user_body
> > options {backtrack=true;}:	
> > 	LCURL command_arguments? RCURL -> ^(USER_COMMAND command_arguments?) |		 			
> > 	 -> USER_COMMAND
> > ;
> 
> With backtracking (which I admit I don't wholly understand yet) I guess
> if it fails on the first alt, it will back-off to the second, empty
> alternative?

Second alt is not taken on my input.



More information about the antlr-interest mailing list