more code completion fun!

[Heiko Leberer]

Daniel Berlin wrote:
> 
> Heiko Leberer <Heiko_Leberer at non.agilent.com> writes:
> 
> > christopher j bottaro wrote:
> > >
> >
> > I'm not familiar with ANTLR, but since it looks quite like to yacc with
> > some additional features, so I comment on what I think you're doing.
> 
> It's not, at all.
> YACC is LALR(1), ANTLR is LL(k).
> 

Not knowing ANTLR, I must admit, that I assumed the lr in ANTLR is a
hint for lalr.

> There is a huge difference in how you write a grammar for an LALR(1)
> generator, and how you write one for an LL(k) generator
> >
> > Those ()? and ()* are great to save some place in writing, but
> > apparently they do not lead to carefully designed rules.
> >
> > How should the parser generator differ between
> >
> > "++ident" as result from "unary_op unary_op postfix_expr"
> >
> > and
> >
> > "++ident" as result from "INC postfix_expr"
> 
> Through the k lookahead.

Then why the non-determinsms?

I think you're confusing something here. The C/C++ grammar allows
generation of both rules. 
Both are *legal*. There is no syntactical way to differ between them,
you need a semantical analysis to choose one or you just need to
formulate your parsing grammar in a way that you get your preferred one.
Semantic analysis is the slow but correct (or more correct) solution for
the conflicts, a solution that would be used if you need to generate
code. A change in your grammer to solve ambiguities, is the faster
solution. This can change the meaning of a rule though, since the
semantic is disregarded, but it would be sufficient for parsing code to
provide a code completion feature.

If you think you can solve this because you have a LL(k) generator,
you're wrong. C/C++ is *not* LL(k).


> 
> I'll stop here, the rest of your commentary just doesn't apply,
> because ANTLR is not LALR.

Yes, however.

Regards,
Heiko

-
to unsubscribe from this list send an email to kdevelop-request at kdevelop.org with the following body:
unsubscribe »your-email-address«