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
_______________________________________________
[email protected] http://lists.gnu.org/mailman/listinfo/help-bison
