more code completion fun!

[Heiko Leberer]

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.


.... 
> also, when i compile my grammer, i get like over a page of non-determinisms,
> but they don't seem to matter at all...  here are some of the ones that
> bother me...
> 
> primary_expr
>         :       (scope)? IDENTIFIER
>         |       INTEGER (DOT INTEGER)?  // non-determinism here
>         |       STRING_LIT
>         |       CHAR_LIT
>         |       OP expression CP
>         ;
> 
> // this rule is fine...
> postfix_expr
>         :       primary_expr    (       (OP (arg_expr_list)? CP)
>                                 |       (OSB expression CSB)
>                                 )?
>                                 (       ((DOT|PTR) postfix_expr)
>                                 )?
>         ;
> 
> // this whole thing apperent causes a lot of non determinisms
> unary_expr
>         :       (unary_op|INCR|DECR)* postfix_expr
>         |       "sizeof" OP returntype CP
>         |       "sizeof" postfix_expr
>         ;

Assuming, that (list)* means, possible multiple instances of one of the
rules in list:

you should redefine (unary_op|INCR|DECR) postfix_expr

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"

Additionally this grammar allows  constructs like "++ ++ ++ 123" from
"INC INC INC postfix_expr).


"5.3" can be the result of 
  postfix_expr -> primary_expr -> INTEGER (DOT INTEGER)

or the result of
  postfix_expr -> primary_expr ()?((DOT) postfix_expr)? -> INTEGER
()?((DOT) INTEGER)


> 
> cast_expr
>         :       (OP returntype CP)? unary_expr  // non determinism here
>         ;
> 
> anyways, antlr is great, maybe the class parser should be rewritten using it.

Heck no, please don't. If yacc forces you to formulate ideas more
carefully, you should stick to that. 


>  its cool how rules can have return types and take arguments and throw
> exceptions and such.  its a lot more pleasureable writing an LL(k) grammer
> also.

It might have been a pleasure, but what you wrote is no LL(k) grammer.
Therfore the non determism (shift/reduce, shift/shift conflicts in
yacc).

>  god, i wish i hadn't have dropped my automata theory class.
> 
> tell me what you all think...potentially useful?
> 

Christopher, this really isn't meant as an insult, but the ease of use
is not the most important  feature of a parser generator. You need to
know, what you want to achieve first, and then how to formulate this.
Some nice features, that allow to save some lines of generator input are
not the way to go, if you don't know what you're doing.

Obviously you can achieve with antlr what you can with yacc as well, but
using those features go hand in hand with being more carefully.

best regards,
Heiko.

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