[antlr-interest] Re: syn pred / lookahaed doesn't work
lgcraymer
lgc at mail1.jpl.nasa.gov
Wed Mar 12 11:43:28 PST 2003
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/
More information about the antlr-interest
mailing list