[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