Re: Performance impact of "redundant" rules

[Hans Aberg]

On 7 Mar 2006, at 10:39, Sylvain Schmitz wrote:

> About LR(1), I recently found out menhir
> <http://pauillac.inria.fr/~fpottier/menhir/menhir.html.en>, which
> implements LR(1) using Pager's method: even today, the direct  
> generation
> of a full-blown LR(1) parser is too expensive.

This sounds interesting: Is this a method to cut down on the  
generation of the LR(1) parser, without affecting the parser  
generated itself? - I thought Bison already had LR(1) in it, and one  
should only need to take away the LALR(1) optimizations to get it  
implemented. But you seem to say, that parser generation phase might  
then become too big.

> Anyway, you would need
> to merge as many LR(1) states as possible if you do not want a  
> dramatic
> performance drop in GLR parsing ... My feeling is that LALR(1) is a
> sensible choice.

LR(1) becomes interesting from unexpected corners: efficient error  
generation and parser that need to display token lookaheads, which  
LALR(1) deliberately both corrupts in its optimizations. This should  
then apply equally well to GLR parsers. What is the reason  
performance drops especially in GLR?

  Hans Aberg