[antlr-interest] Re: Is it because of buggy antlr?
rmsanjivp <rmsanjivp at yahoo.com>
rmsanjivp at yahoo.com
Tue Jan 21 09:42:25 PST 2003
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/
More information about the antlr-interest
mailing list