|SLR and LR(1) Differences: A Recap email@example.com (Vladimir Lushnikov) (2006-08-10)|
|Re: SLR and LR(1) Differences: A Recap firstname.lastname@example.org (email@example.com) (2006-08-12)|
|Re: SLR and LR(1) Differences: A Recap firstname.lastname@example.org (2006-08-14)|
|Re: SLR and LR(1) Differences: A Recap email@example.com (Vladimir Lushnikov) (2006-08-18)|
|Re: SLR and LR(1) Differences: A Recap firstname.lastname@example.org (Andru Luvisi) (2006-08-19)|
|Re: SLR and LR(1) Differences: A Recap email@example.com (Rob Arthan) (2006-10-03)|
|Date:||14 Aug 2006 15:09:51 -0400|
|Organization:||Department of Computer Science, University of Copenhagen|
|Posted-Date:||14 Aug 2006 15:09:51 EDT|
"Vladimir Lushnikov" <firstname.lastname@example.org> 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.
Return to the
Search the comp.compilers archives again.