Re: SLR and LR(1) Differences: A Recap

Torben Ęgidius Mogensen wrote:
> "Vladimir Lushnikov" <vladimir.d.lushnikov@gmail.com> writes:
>
>
> > I guess my question is how the SLR tables are constructed compared to
> > LR(1) tables and how they differ?
>
> I won't go into details, as you can pick those up in most compiler
> textbooks (such as the old "Dragon Book" by Aho, Sethi & Ullman).
>
> A more relevant question for compiler writers is "does it matter?".
> IMO, it matters little -- while LR(1) (or LALR(1)) might resolve some
> conflicts that SLR parsers do not, you do not escape the need to
> rewrite your grammer to avoid conflicts, and in my experience the
> cases where LR(1) makes this easier are few.
>
> LR(1) parse tables are much larger than SLR, whereas LALR(1) tables
> are no bigger. That makes LALR(1) popular for parser generators, and
> you can argue that this makes SLR uninteresting. I have, however,
> found that most people think in terms of FOLLOW when resolving
> conflicts in LALR(1) parsers, so they might as well be SLR.
>
> In short, I think the advantages of LALR(1) and LR(1) over SLR are
> overrated. I do, however, find that SLR (or the other LR variants) is
> much easier to use than LL(1), partly because it doesn't require left
> recursion removal and left-factoring and partly because SLR handles
> operator precedence more easily.


I agree, the reason I was asking is to clarify (the seemingly trivial)
distinction between constructing SLR and LR(1) tables because I am
trying to see whether there would be any difference if the tables were
used (with an ambiguous grammar) in a GLR parsing algorithm.

Return to the comp.compilers page.
Search the comp.compilers archives again.