|
From: | Hans Aberg |
Subject: | Re: Performance impact of "redundant" rules |
Date: | Tue, 7 Mar 2006 15:01:47 +0100 |
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>, whichimplements LR(1) using Pager's method: even today, the direct generationof 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 needto merge as many LR(1) states as possible if you do not want a dramaticperformance 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
[Prev in Thread] | Current Thread | [Next in Thread] |