Introduction
SLR places a reduction on every token in FOLLOW(). FOLLOW is a global set: it collects every token that can follow anywhere in the grammar, even when, in the particular state the parser is in, only a few of those tokens can actually come next. The false conflicts that result (the L = R grammar is the standard example) disappear if each item carries the exact tokens that may follow it in that context.
That is the idea of canonical LR(1) parsing (CLR, or simply LR(1)): items with a lookahead terminal. CLR is the most powerful of the one-token LR methods but can have many more states. LALR(1) (lookahead LR) merges CLR states that have the same items apart from the lookaheads. It has exactly as many states as SLR and LR(0), is almost as powerful as CLR, and is the method used by Yacc and Bison. This note builds both, compares all four LR methods, and explains what merging can and cannot break.
Prerequisites
- LR(0) and SLR(1) Parsing: items, CLOSURE, GOTO, the LR driver and the conflict tests.
- FIRST sets of strings (see the note FIRST and FOLLOW Sets), used to compute lookaheads.
Core concepts
| Term | Definition |
|---|---|
| LR(1) item | : an LR(0) item (the core) plus a lookahead terminal (or ) |
| Meaning of the lookahead | Reduce by in a state containing only when the next token is |
| Canonical LR(1) collection | All LR(1) item sets reachable from CLOSURE() |
| Core of a state | The set of LR(0) items obtained by dropping all lookaheads |
| LALR(1) states | The CLR states with identical cores merged into one, lookaheads united |
Lookahead restricts reduce actions only in completed items. In a noncomplete item it also propagates during closure through ; it is not merely carried unchanged until completion.
Algorithms
CLOSURE and GOTO with lookaheads
CLOSURE1(I)
repeat
for each item [A -> alpha . B beta, a] in I, B a nonterminal
for each production B -> gamma
for each terminal b in FIRST(beta a)
add [B -> . gamma, b] to I
until no item is added
return I
GOTO1(I, X)
return CLOSURE1({ [A -> alpha X . beta, a] : [A -> alpha . X beta, a] in I })The lookahead of a new item is FIRST of what follows in the item, followed by the item's own lookahead. If is nullable, the lookahead itself is inherited; otherwise only FIRST() is used.
The collection is built from CLOSURE1() with GOTO1, exactly as in the LR(0) case. Table filling: shift entries as in SLR; for with , ACTION[] reduce , and only on ; accept on .
LALR by merging
LALR-FROM-CLR(C)
group the CLR states by core
for each group, form one state: the union of its LR(1) items
GOTO of a merged state on X = the merged state containing GOTO of any member
build the table as for CLR; conflicts in the merged table mean "not LALR(1)"GOTO is well defined after merging, because states with the same core have successors with the same core. Building every CLR state first can be expensive; practical generators compute LALR lookaheads directly on the LR(0) automaton by propagating them, with the same result.
Worked examples
The grammar ,
The canonical LR(1) collection has 10 states:
| State | Items | Transitions |
|---|---|---|
| , , , | : 1, : 2, : 3, : 4 | |
| none | ||
| , , | : 5, : 6, : 7 | |
| , , | : 8, : 3, : 4 | |
| none | ||
| none | ||
| , , | : 9, : 6, : 7 | |
| none | ||
| none | ||
| none |
( abbreviates two items, one with each lookahead.) Why two copies: a derived for the first of is followed by the second , which begins with c or d; a derived for the second one is followed by the end of input. States 3, 4, 8 serve the first ; states 6, 7, 9 serve the second.
LALR merge. The pairs , , have the same cores. Merging them gives 7 states, the same number as the LR(0) automaton, with lookaheads in the merged complete items. No conflict arises, so the grammar is LALR(1); it is in fact LR(0).
Parsing c d d with the CLR table: shift 3, shift 4, reduce , reduce , shift 7, reduce , reduce , accept. The LALR parser does the same moves with state 4 in place of 7.
Error detection. On the invalid input c d (a single ), the CLR parser stops in on : is not a lookahead there, so it reports the error before any reduction. The LALR parser, in the merged state with lookaheads , first reduces and and only then reports the error. LALR and SLR may perform extra reductions before detecting an error, but never shift an erroneous token.

Computing lookaheads: of the L = R grammar
Start from and close:
- follows the dot with nothing after it, so the lookahead is FIRST(): add and .
- In , is followed by
= R, so the new -items get FIRST() : , . - In , nothing follows : add .
- In , nothing follows : add , .
The item has lookahead only. After reading , the state holds and , so is reduced on only, and = is free for the shift. SLR used FOLLOW() instead, and conflicted.
Where SLR fails but LALR succeeds
For , , , the CLR collection has 14 states and LALR merges them to 10, the LR(0) count. The state that caused the SLR conflict now has items and : reduce only on , shift on =, no conflict. The grammar is LALR(1) and LR(1), but not SLR(1).
Where LALR fails but CLR succeeds
S -> a A d | b B d | a B e | b A e
A -> c
B -> cThe CLR collection has 14 states, including
- , reached on
a c, and - , reached on
b c.
Each is conflict-free, so the grammar is LR(1). They have the same core , so LALR merges them into : on d and on e it can reduce by either production. LALR has 13 states and two reduce-reduce conflicts, so the grammar is not LALR(1). It is not SLR(1) either, since FOLLOW() FOLLOW() .
Lookaheads separating two -reductions
For S -> A a A b | B b B a, A -> eps, B -> eps, the initial LR(1) state contains and : the lookahead of each is the terminal that follows the first or in its body. The four tables all have 10 states.
| Method | Conflicts in state 0 |
|---|---|
| LR(0) | reduce-reduce on a, b and (complete non-augmented production items reduce on every token; the completed augmented start accepts only on the endmarker) |
| SLR(1) | reduce-reduce on a and b, since FOLLOW() FOLLOW() |
| LALR(1), CLR(1) | none: on a only, on b only |
Why merging never creates a shift-reduce conflict
Suppose the merged state has a shift-reduce conflict on : it contains a complete item and an item . The complete item came from some CLR state in the group. All states in the group have the same core, so also contains (with some lookahead), and shifts on . Then itself already had the conflict, and the grammar was not LR(1). Hence: if a grammar is LR(1), its LALR table can have reduce-reduce conflicts but never shift-reduce conflicts.
Comparison of the LR methods
| Property | LR(0) | SLR(1) | LALR(1) | CLR(1) |
|---|---|---|---|---|
| Items | LR(0) | LR(0) | LR(1), merged by core | LR(1) |
| Ordinary reduction , , on | every token | FOLLOW() | merged lookaheads | exact lookaheads |
| Number of states | , often much more | |||
| Grammar class | smallest | larger | larger | largest of the four |
| Error detection | may reduce first | may reduce first | may reduce first | before any reduction on the bad token |
Here is the number of LR(0) states. The LALR lookahead set of a complete item is always a subset of FOLLOW of its head, which is why every SLR(1) grammar is LALR(1).
Grammar classes and languages
- Grammars: LR(0) SLR(1) LALR(1) LR(1), every inclusion strict, with the examples above as witnesses: the expression grammar (SLR, not LR(0)), the
L = Rgrammar (LALR, not SLR), thea A dgrammar (LR(1), not LALR). - LL(1) grammars are all LR(1). They are not all LALR(1): for example,
S -> ( X | E ] | F ),X -> E ) | F ],E -> A,F -> A,A -> epsis LL(1) and LR(1), but its LALR table has reduce-reduce conflicts.S -> A a A b | B b B a,A -> eps,B -> epsis LL(1) and LALR(1) but not SLR(1). - Ambiguous grammars belong to none of these classes.
- Languages: a language has an SLR(1) grammar if and only if it has an LALR(1) grammar, if and only if it has an LR(1) grammar, if and only if it is a deterministic context-free language (see Deterministic PDAs and DCFLs). The displayed ACTION-table convention uses an end marker to detect acceptance; do not transfer a prefix-property characterization from formal zero-lookahead models without end detection to this convention. So the methods differ in which grammars they accept, not in which languages they can describe with some grammar.
Important properties and observations
- State counts. For the same grammar: LR(0) SLR LALR CLR. Examples: 7, 7, 7, 10 for ; 10, 10, 10, 14 for the
L = Rgrammar. - The expression grammar , , has 12 states for LR(0), SLR and LALR, and 22 for CLR: 10 of the 12 cores occur in two CLR states that differ only in their lookaheads. In each pair, exactly one copy has among its lookaheads; the other is reached only inside parentheses, where
)plays the role of . Its only LR(0) conflicts are the shift-reduce entries of and on*; SLR, LALR and CLR have none. - What merging can do. Merge an LR(1) grammar's states and you may get new reduce-reduce conflicts, never new shift-reduce conflicts, and possibly later error detection.
- Lookahead propagation. In CLOSURE1, the lookahead of is FIRST(). Taking FOLLOW() instead turns CLR into something close to SLR and loses its power.
- Yacc and Bison build LALR(1) tables and resolve remaining conflicts by default rules (shift over reduce; the earlier production for reduce-reduce) or by declared precedence and associativity.
Common misconceptions.
- "LALR has fewer states than SLR." It has the same number.
- "LALR merging can introduce shift-reduce conflicts." Not for an LR(1) grammar.
- "CLR parsers accept more languages than SLR parsers." They accept more grammars; the languages are the same, the deterministic context-free languages.
- "Every LL(1) grammar is LALR(1)." No; it is LR(1), but some LL(1) grammars are not LALR(1).
GATE examination perspective
- Containment questions. LR(0) SLR LALR CLR for grammars; LL(1) LR(1). Watch for options claiming LL(1) LALR(1) or LL(1) SLR(1): both are false.
- State counts. " states for SLR, for LALR, for CLR": the true relation is .
- Merging conflicts. "If a CLR(1) table has no conflict, the LALR(1) table may have": reduce-reduce conflicts only.
- Lookahead computation. Compute FIRST() for the items added by closure; a nullable passes the parent's lookahead down.
- One core, several lookaheads. In of the
L = Rgrammar, appears with=(through ) and with (through ). Options that list only one lookahead are wrong. - -productions in LR(1) items. is a complete item from the start; its lookahead decides where the empty reduction goes.
- Which grammar is which. Locate the states with complete items and check lookaheads; for an LALR question, merge same-core states and recheck.
Summary
Sources
- A. V. Aho, M. S. Lam, R. Sethi, J. D. Ullman, Compilers, Principles, Techniques, and Tools, 2nd ed., Pearson Addison-Wesley, 2007: Section 4.7.1 (canonical LR(1) items), Section 4.7.2 (constructing LR(1) sets of items), Section 4.7.3 (canonical LR(1) parsing tables), Section 4.7.4 (constructing LALR parsing tables), Section 4.7.5 (efficient construction of LALR parsing tables), Section 4.9.1 (the parser generator Yacc).