[antlr-interest] Re: syn pred / lookahaed doesn't work

[lgcraymer]

One comment on code generation here:  internally, ANTLR rewrites
    ((foo)=>foo)*
as
    )    ((foo)=>foo)+
    | //nothing
    )

In the second form, the foo synpred does not make any sense and the 
error message that you get reports that face.  This could be fixed, 
but that is not likely to happen in ANTLR 2.

As far as a performance difference between the iterative version and 
the recursive version, the difference is negligible--the big penalty 
is  (statement)=>statement  which forces you to match statement twice 
for each call.

--Loring


--- In antlr-interest at yahoogroups.com, "Albert Huh" <albert.huh at e...> 
wrote:
> You're right about it not being ambiguous.  It's an issue with the 
antlr code generation.
> 
> lgcraymer actually posted a version that is better than mine.  you 
should use his.
> 
> But ya, you're right about it not being ambiguous.  It's the way 
antlr generates code.  Check out 
http://www.antlr.org/doc/lexer.html#Limitations_of_Nongreedy_Subrules 
for an example.
> 
> The problem here is that the first thing can be either a function or 
a statement.  Look at the generated code and you will see how antlr 
decides to exit the loop.
> 
> 
> 
> 
> -----Original Message-----
> From: Gunnar Wagenknecht [mailto:kreismeister at y...]
> Sent: Wednesday, March 12, 2003 12:26 AM
> To: antlr-interest at yahoogroups.com
> Subject: [antlr-interest] Re: syn pred / lookahaed doesn't work
> 
> 
> 
> --- In antlr-interest at yahoogroups.com, "Albert Huh" 
<albert.huh at e...> 
> wrote:
> 
> > ambiguity with k=2
> > ------------------
> > 1) the second token of a function can be either an IDENTIFIER 
> or "function"
> > 2) the second token of a variableDeclaration is an IDENTIFIER
> > 3) we know that variableDeclaration is a statement
> > 4) so a statement looks exactly like a function at k=2
> 
> Mhm, but I thought this is not an ambiguity because if the second 
> token of a function is an IDENTIFIER than the first token of a 
> function is NOT "static" or "ecit".
> 
> > i'm probably not stating anything new here to anybody.  i *think* 
> this is a linear approximation issue, can somebody else confirm 
this?
> 
> What the hack is that?
> 
> > alternatively, you can get rid of teh warning with a combination 
of 
> recursion and syntactic predicates.  try rewriting your 
statementList 
> rule like this:
> > 
> > statementList:
> >   (statement statement)=>statement statementList
> >   |(statement)=>statement
> >   | //empty rule, do nothing
> > ;
> 
> 
> Thank you, that was something I was trying without getting warnings 
> but I couldn't finished it. Now I will try it. I'm wondering if this 
> construct slows down the generated parser in a very bad way. That's 
> why I threw away this solution.
> 
> Cu, Gunnar
> 
> 
>  
> 
> 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/