[antlr-interest] Wrong rule in parser gets matched

[Dan Spaven]

Thanks Bryan that cleared a few things up. The ( )* is sensorCont is a 
mistake, it was supposed to be an optional append that i've now changed to ( 
)?

With regards to the tree created i wouldn't be surprised if it looks a bit 
suspicious i'm still very much finding my way on that front. I'm not sure, 
but i don't think in my case the structure of the tree matters that much as 
i'm just using it to emit bytecode. The only reason i am infact constructing 
a tree is i wanted to record information about the function calls before 
emitting any bytecode.

Thanks for your help,

Dan


>From: "Bryan Ewbank" <ewbank at gmail.com>
>To: antlr-interest at antlr.org
>Subject: Re: [antlr-interest] Wrong rule in parser gets matched
>Date: Sun, 26 Feb 2006 20:18:51 -0500
>
>Dan,
>
>The problem is, I think, that you didn't do what you thought you did in the
>grammar.  Specifically, IDENT does not match an expression because
>unaryExpression **requires** either a PLUS or MINUS before the identifier.
>What you probably want is this:
>
>     // first and second alternative consume unary operators; third 
>alternative
>     // is matched when there are no unary operators left...
>     unaryExpression
>             :       MINUS^ unaryExpression
>{System.out.println("matched UNARY MINUS");}
>             |       PLUS^ unaryExpression
>{System.out.println("matched UNARY PLUS");}
>             |       atom
>{System.out.println("matched bar atom");}
>             ;
>
>sensorCont still looks a bit suspect with the "is" alternative -- why
>is there ( )*
>around the trailing "as" suffix, and why is the tree-shape different than 
>for
>the "as" alternative?
>
> > statement
> >         :       sensorDec
> >         |       expression
> >         ;
> >
> > expression
> >         :       addExpr
> >                 ( ASSIGN^ expression
> >                 | "is"^ type ("as" mode)* // require addExpr to be IDENT
> >                 | "as"^ mode              // require addExpr to be IDENT
> >                 )?
> >         ;
>
>This focuses on the syntax of the language, rather than the meaning of that
>syntax.
>
>Hope this helps,
>- Bryan