[antlr-interest] Re: Is it because of buggy antlr?

[rmsanjivp <rmsanjivp at yahoo.com>]

Thanks,

That solves my problem. Thanks to Ter also for his valuable peice of 
advice.

Sanjiv

--- In antlr-interest at yahoogroups.com, "Zukowski, Monty" 
<mzukowski at y...> wrote:
> You can't just call a rule out of the blue if it is not a start 
rule.  Easy
> enough to fix, just make a new rule that's not referenced by 
anything else:
> 
> topLevelExpr: expr;
> 
> Monty
> 
> -----Original Message-----
> From: rmsanjivp <rmsanjivp at y...> [mailto:rmsanjivp at y...]
> Sent: Monday, January 20, 2003 9:44 PM
> To: antlr-interest at yahoogroups.com
> Subject: [antlr-interest] Re: Is it because of buggy antlr?
> 
> 
> Thanks Loring,
> 
> But that was a typo from my side. I really had hard time figuring 
> out the problem with the following grammar:
> 
> 
> expr
>  : e1 ((PLUS | MINUS) e1)*
>  ;
>  
>  e1
>   : e0 ( POWER e1)? // to make POWER tree as right associative
>   ;
> 
> e0: ID;
> 
> If it is a small example like this then it works fine because in 
the 
> c++ code generated by ANTLR does not throw an exception if the next 
> token is the EOF.
> 
> But I have a grammar where I have a number of tokens and at least 
11 
> levels of descent like..
> 
> e1: e2 (OP1 e2)*;
> e2: e3 (OP2 e3)*
> ...
> e10: e11 (OP10 e10)?;
> e11: ID;
> 
> On Observing the code generated for this bug grammar I figured out 
> that in the method for rule e10 an exception is thrown if the next 
> lookahead symbol is not any of OP1, op2, ..., OP10. Even when rule 
> e11 can lead to the terminal the method for rule e10 throws an 
> exception for EOF. And if I have "p1+p2" as an input then it 
> recognizes upto p2 but then in rule e10 the next look ahead is EOF 
> and hence it throws an exception.
> 
> Could anyone please throw some light on such behavior?
> 
> thanks,
> Sanjiv
> 
> 
> 
> 
> --- In antlr-interest at yahoogroups.com, "lgcraymer <lgc at m...>" 
> <lgc at m...> wrote:
> > Sanjiv--
> > 
> > Actually, there is a bug in your grammar.  Change expr to
> > 
> > expr
> >    :
> >    e1 ( ( PLUS | MINUS ) e1 )*
> >    ;
> > 
> > 
> > and it might work.  "|" separates alternative blocks so that your 
> > version gives
> > 
> > expr
> >    :
> >    e1
> >    (      PLUS
> >    |      MINUS e1
> >    )+
> >    ;
> > so that P1 - p2 would work, but not P1 + p2.
> > 
> > --Loring
> > 
> > --- In antlr-interest at yahoogroups.com, "rmsanjivp 
> <rmsanjivp at y...>" 
> > <rmsanjivp at y...> wrote:
> > > Consider the following rules:
> > > 
> > > expr
> > >  : e1 (PLUS | MINUS e1)*
> > >  ;
> > > 
> > > e1
> > >  : e0 ( POWER e1)? // to make POWER tree as right associative
> > >  ;
> > > 
> > > e0: ID;
> > > 
> > > 
> > > For the following parser the generated code in C++ when 
compiled 
> and 
> > > run gives unexpected token for input "P1 + p2"
> > > 
> > > If the right associative part is changed to
> > > 
> > > e1
> > >  : e0 ( POWER e0)*
> > >  ;
> > > 
> > > then all works fine except that the operator POWER is treated 
as 
> > > right associative.
> > > 
> > > Any idea how to make an operator left associative?
> > > 
> > > Thanks,
> > > Sanjiv
> 
> 
>  
> 
> Your use of Yahoo! Groups is subject to 
http://docs.yahoo.com/info/terms/


 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/