CEDET

Joseph,

[...]
> I wrote my expression rules mimicking the Java grammar, splitting off
> the unary expressions like thus:
> 
> expr : NUMBER_LITERAL
>      | STRING_LITERAL
>      | name
>      | id BANG NUMBER_LITERAL
>      | expr arguments
>      | expr binop expr
>      | unary_expr
>      | expr BACKTICK id_or_number
>      | PAREN_BLOCK
>      | BRACK_BLOCK
>      | expr COLON_COLON typeexpr
>      | bindingexpr
>      | LET letbinding_list IN expr
>      | expr WHERE letbinding_list
>      | expr WITH LBRACK_RBRACK
>      ;
> 
> unary_expr : unary_expr_not_minus
>            | MINUS unary_expr %prec UMINUS
>            ;
> 
> unary_expr_not_minus : NOT unary_expr
>                      | TILDE unary_expr
>                      | LBRACK_RBRACK unary_expr
>                      | LT_GT unary_expr
>                      ;
> 
> MINUS and UMINUS have precedence and associativity set as well
> according to the language definition:
> 
> %left     PLUS MINUS PLUS_PLUS
> %left     MULT SLASH MULT_MULT SLASH_SLASH
> %nonassoc UMINUS
> 
> Unfortunately, for some strange reason, the wisent parser decides
> that these two unary rules are useless:
> 
> Useless nonterminals:
> 
>    unary_expr
>    unary_expr_not_minus
> 
> Under what circumstances can a rule that is part of a grammar be
> eliminated like this?

It's difficult to say without viewing the whole grammar.  However,
based on what I saw in the Java grammar, I wonder if the
`unary_expr_not_minus' definition shouldn't rather be something like
this:

unary_expr_not_minus : NOT expr
                     | TILDE expr
                     | LBRACK_RBRACK expr
                     | LT_GT expr
                     ;

Probably you will have to thoroughly analyze the automaton produced
from you grammar (M-x wisent-toggle-verbose-flag before compiling your
grammar).

Perhaps reading "Understanding the automaton" in the Wisent's manual,
and looking at the Bison's manual could be useful too.

Hope it helps.

Good luck!
David