[antlr-interest] A rule ANTLR 3 doesn't like [Re: ANTLR 3 diagnostics]

Terence Parr parrt at cs.usfca.edu
Thu Dec 27 15:42:19 PST 2007


Hi Chap, try removing side effects from preds...no telling how many  
times they exec now.

Also use {...}?=> pred not {..}? to force including in DFA decision  
maker.
Ter
On Dec 27, 2007, at 3:28 PM, J Chapman Flack wrote:

>
> J Chapman Flack wrote:
>> J Chapman Flack wrote:
>>> Now the v3 org.antlr.Tool gives the following stack
>>> overflow, and I am seeking suggestions for any reasonably
>>> ...
>> or I could have read the docs ... -Xwatchconversion seems to
>> get me in the neighborhood. Sorry for the bandwidth.
>
> The offending rule is one that had already required creativity
> in getting ANTLR 2 to accept it. I suppose it may require
> different creativity to get v3 to accept it.
>
> The goal is to parse n (a parameter passed by caller) NUMBERs
> separated by delimiter tokens of token type tt (another parameter,
> but we are confident tt != SEMI). If the caller passes 0 for n,
> take as many as possible.  Looks like this, converted from ANTLR 2:
>
> numeric_aggregate[int n, int tt]
>                 @init {
>                   boolean limit = ( 0 != n );
>                 }
>                 : NUMBER
>                   ( options { greedy = true; } :
>                     { (!limit || (--n > 0)) && LA(1) == tt }?  
> ~( SEMI )
>                     NUMBER
>                   )*
>                   { !limit || 0 == n }?
>                 ;
>
> Should this work in ANTLR 3?  Or is there a more-recommended way
> of expressing this rule?
>
> I'll try with the more recent build tomorrow.
>
> Thanks,
> -Chap



More information about the antlr-interest mailing list