CLR(1) and LALR(1)
LR(1) items with lookaheads, the closure rule, the canonical LR(1) automaton and table, the merging of states with equal cores that gives LALR(1), what merging can and cannot break, state counts, and a grammar that is LR(1) but not LALR(1).
Why it exists
SLR(1) decides a reduction with FOLLOW(), the set of every token that can follow anywhere. In one particular state fewer tokens are actually possible, so SLR sometimes sees a conflict that is not real (the grammar). The remedy is to remember, inside each item, which tokens can follow in this context. That gives the canonical LR(1) parser, the most powerful of the deterministic methods, with a big table. LALR(1) then shrinks the table to the size of the LR(0) one by merging states that differ only in lookaheads, keeping most of the power. Yacc and Bison build LALR(1) parsers.
Prerequisites
You need items, closure and goto from LR(0) and SLR, and FIRST sets (FIRST and FOLLOW).
Precise definitions
LR(1) item. A pair : an LR(0) item (the core) plus a lookahead terminal (or $). Meaning: the parser has seen and hopes to see , and when the whole right side has been seen it may reduce only if the next token is . Items with the same core and different lookaheads are written together: .
Closure of a set of LR(1) items. Repeat: for every item in the set, every production and every terminal in , add . Here means FIRST of the string followed by : it is , plus if can vanish. The reasoning: after comes , and then whatever comes after , namely .
Goto is as before: move the dot over in every item that has after the dot, keep the lookahead, then close. The start state is the closure of .
Canonical LR(1) (CLR(1)) table. From the collection of LR(1) item sets: shifts and GOTO as in SLR; for a complete item with , ACTION[, ] = reduce — only on the lookahead ; gives accept. A grammar is LR(1) if there is no conflict. Because lookaheads are exact, CLR(1) detects errors without any extra reductions.
Size. States with the same core but different lookaheads are different states, so the canonical LR(1) automaton can have many more states than the LR(0) automaton (22 against 12 for the standard expression grammar; hundreds or thousands for a programming language).
LALR(1). Take the canonical LR(1) states and merge those that have the same core (the same LR(0) items), taking the union of the lookaheads item by item. The merged automaton has exactly the states of the LR(0) automaton (so the same number as SLR(1)); the transitions are those of the merged states. The table is filled as for CLR(1) but with the merged lookaheads. (In practice the lookaheads are computed directly from the LR(0) states by propagation, without building the whole LR(1) automaton.)
What merging does:
- It can never create a shift-reduce conflict. Shift actions depend only on the core (the symbols after the dot), which is identical in the merged states; a new conflict would need a reduce lookahead equal to a shift symbol in the merged state, and that already existed in one of the merged states (where the same core and shift were present, with the lookahead of the other). So if the canonical LR(1) table has no shift-reduce conflict, neither has the LALR(1) table.
- It can create reduce-reduce conflicts. Two complete items in one core may have disjoint lookaheads in each separate state but overlapping lookaheads after the union.
- It can delay error detection: the parser may perform some reductions on an erroneous token (because merged lookaheads are larger), but it still never shifts the bad token.
So: (as classes of grammars), where means "properly contained", and the table sizes are the same for LR(0), SLR(1), LALR(1) and larger for LR(1).
How it works
Canonical LR(1) item sets for the standard small grammar , . State 0 is the closure of : closing with lookahead $ adds and with lookahead FIRST() = {c, d}. Following the gotos you get 10 states, while the LR(0) automaton has 7: for example the items appear in states 3 (lookahead c/d) and 6 (lookahead $), which have the same core.
Canonical LR(1) item sets of S → C C, C → c C | d: start
Computed by a script, not typed- 1S → C C
- 2C → c C
- 3C → d
| state | LR(1) items | transitions |
|---|---|---|
| I0 | S' → · S, $ S → · C C, $ C → · c C, c/d C → · d, c/d | |
| I1 | ||
| I2 | ||
| I3 | ||
| I4 | ||
| I5 | ||
| I6 | ||
| I7 | ||
| I8 | ||
| I9 |
state 0
Step 0
An LR(1) item is [A → α · β, a]: the usual item plus the lookahead terminal a that may follow the production when it is reduced. In the closure of [A → α · B β, a] add [B → · γ, b] for every production B → γ and every b in FIRST(βa). The start state is the closure of [S' → · S, $].
LALR(1) merges the pairs with equal cores: (3, 6), (4, 7) and (8, 9). The result has 7 states, with unions of lookaheads such as in the merged state 4-7.
Merging LR(1) states with equal cores (LALR): start
Computed by a script, not typed- 1S → C C
- 2C → c C
- 3C → d
| LALR state | merged from | items with lookaheads | |
|---|---|---|---|
| I0 | |||
| I1 | |||
| I2 | |||
| I3+I6 | |||
| I4+I7 | |||
| I5 | |||
| I8+I9 |
Step 0
Two LR(1) states have the same core if they have the same items when the lookaheads are ignored. LALR(1) merges all states with the same core into one, taking the union of the lookaheads. The number of states becomes the number of LR(0) states.
What can go wrong is shown by the grammar , , . After a c the lookahead tells from (d means , e means ); after b c the other way round. In canonical LR(1) those are two different states, so there is no conflict. LALR merges them (the same core: , ) and the lookahead sets overlap: a reduce-reduce conflict. The grammar is LR(1) but not LALR(1).
A grammar that is LR(1) but not LALR(1): start
Computed by a script, not typed- 1S → a A d
- 2S → b B d
- 3S → a B e
- 4S → b A e
- 5A → c
- 6B → c
| state | items with lookaheads | verdict |
|---|---|---|
| I6 (after a c) | ||
| I9 (after b c) | ||
| merged state |
Step 0
Grammar: S → a A d | b B d | a B e | b A e, A → c, B → c. After reading a c, the parser is in a state with the items A → c · and B → c ·. The lookaheads decide which reduction is right.
Finally the grammar from the previous page. LALR(1) keeps just one state for , , and the lookahead of the reduction there is only $, so no conflict: it is LALR(1) (and LR(1)) but not SLR(1).
The same grammar has a conflict-free LALR(1) table: start
Computed by a script, not typed- 1S → L = R
- 2S → R
- 3L → * R
- 4L → id
- 5R → L
| state | = | * | id | $ | S | L | R |
|---|---|---|---|---|---|---|---|
| 0 | |||||||
| 1 | |||||||
| 2 | |||||||
| 3 | |||||||
| 4 | |||||||
| 5 | |||||||
| 6 | |||||||
| 7 | |||||||
| 8 | |||||||
| 9 |
Step 0
Fill the table state by state. For an item A → α · a β (a terminal) enter shift to goto(I, a); for an item A → α · B β enter goto(I, B) in the GOTO part; for a complete item A → α · reduce only on the (merged) lookahead of the item; for S' → S · enter accept on $. A cell that gets two entries is a conflict.
Worked examples
EX 1Closure with lookaheads
EasyFor , : start with . The dot is before , with and lookahead $: add . The dot is before the first , (the second one), lookahead $: FIRST() = {c, d}, so add and . The dot before c or d needs no more. State 0 has these four items. Compare with the LR(0) closure, which has the same four items without lookaheads.
EX 2Read reduce entries from the lookahead
EasyIn state 4 of the canonical automaton, the item gives reduces on c and d only; in state 7 the item reduces on $ only. The table rows are r3 r3 - and - - r3. After merging (LALR) the merged state has r3 r3 r3. SLR(1) would use FOLLOW() = {c, d, $}: the same row here. The three methods differ only when FOLLOW is larger than the real lookahead.
EX 3Count states
Medium, : LR(0) 7 states, SLR(1) 7, LALR(1) 7, canonical LR(1) 10 (pairs 3-6, 4-7, 8-9 have equal cores, so ). For the expression grammar: 12, 12, 12 and 22. Rule: LALR(1) states = LR(0) states always; CLR(1) states are at least as many. A question may give the CLR(1) states and ask how many LALR(1) states there are: count the distinct cores.
EX 4Where does the conflict come from?
MediumIn the grammar the two states after a c and b c have the lookaheads
| after | ||
|---|---|---|
a c | d | e |
b c | e | d |
Union after merging: both items have d/e. On d, reduce or ? Reduce-reduce conflict, though each unmerged state was unambiguous. This is the only kind of conflict LALR(1) can add to LR(1). Note that SLR(1) also fails this grammar (FOLLOW() = FOLLOW() = {d, e}).
EX 5True or false
GATE level(a) "Every LR(1) grammar is LALR(1)": false (the grammar above). (b) "Every LALR(1) grammar is LR(1)": true. (c) "LALR(1) and SLR(1) tables have the same number of states": true. (d) "LALR(1) merging can introduce a shift-reduce conflict": false; only reduce-reduce. (e) "An LALR(1) parser accepts the same language as the canonical LR(1) parser for a grammar that is LALR(1)": true. (f) "An LALR(1) parser may make extra reductions before detecting an error that the canonical LR(1) parser detects immediately": true, but it never shifts the erroneous token. (g) "Canonical LR(1) automaton always has more states than LR(0)": false in general: it has at least as many; for some grammars they are equal (the grammar of the comparison page has 10 in both).
Cheat box
Cheat box
- LR(1) item . Closure: for add for . Start: .
- Reduce only on the item's lookahead. CLR(1) has the most states.
- LALR(1): merge LR(1) states with equal cores, union the lookaheads; states = LR(0) states.
- Merging never creates shift-reduce conflicts; it may create reduce-reduce conflicts.
- Power: LR(0) ⊂ SLR(1) ⊂ LALR(1) ⊂ LR(1) (proper subsets). Table size: LR(0) = SLR = LALR ≤ LR(1).
- Example numbers: : 7 / 10; expression grammar: 12 / 22.
Traps and GATE patterns
Connections
Builds on
Across subjects
No cross-subject links yet.
LALR(1) builds on the item sets of LR(0) and SLR and uses the table-driven LR driver. FIRST sets are needed for the lookaheads (FIRST and FOLLOW). All four classes and LL(1) are compared with examples in the parser hierarchy.
PYQs
6 previous year questions from your book. I re-solved each one myself (2 by running or simulating, 4 by reasoning only); the book's key is shown next to my answer. All PYQs
Which one of the following statements is TRUE?
- (a)The LALR(1) parser for a grammar G cannot have reduce – reduce conflict if the LR(1) parser for G does not have reduce – reduce conflict.
- (b)Symbol table is accessed only during the lexical analysis phase.
- (c)Data flow analysis is necessary for run-time memory management.
- (d)LR(1) parsing is sufficient for deterministic context – free languages
Consider the following grammar G. S → F | H F → p | c H →d | c Where S, F and H are non-terminal symbols, p, d and c are terminal symbols. Which of the following statement(s) is/are correct? S1: LL(1) can parse all strings that are generated using grammar G. S2: LR(1) can parse all strings that are generated using grammar.
- (a)Only S1
- (b)Only S2
- (c)Both S1 and S2
- (d)Neither S1 nor S2
A canonical set of items is given below: S → L. > R Q → R. On input symbol < the set has:-
- (a)a shift-reduce conflict and a reduce-reduce conflict.
- (b)a shift-reduce conflict but not a reduce-reduce conflict.
- (c)a reduce-reduce conflict but not a shift-reduce conflict.
- (d)neither a shift-reduce nor a reduce-reduce conflict. COMPILER DESIGN
Consider the following two sets of LR(1) items of an LR(1) grammar. X→c. X, c/d X→ c. X, $ X-> .cX, c/d X→ .cX, $ X→ .d, c/d X→ .d, $ Which of the following statements related to merging of the two sets in the corresponding LALR parser is/are FALSE? 1. Cannot be merged since look ahead is different. 2. Can be merged but will result in S-R conflict. 3. Can be merged but will result in RR conflict. 4. Cannot be merged since goto on c will lead to two different sets.
- (a)1 only
- (b)2 only
- (c)1 and 4 only
- (d)1, 2, 3 and 4
An LALR(1) parser for a grammar G can have shift-reduce (S-R) conflicts if and only if
- (a)The SLR(1) parser for G has S-R conflicts
- (b)The LR(1) parser for G has S-R conflicts
- (c)The LR(0) parser for G has S-R conflicts
- (d)The LALR(1) parser for G has reduce-reduce conflicts
Consider the following expression grammar. The
seman-tic rules for expression calculation are stated
next to each grammar production.
E → number
E.val = number. val
| E '+' E
E(1).val = E(2).val + E(3).val
| E '×' E
E(1).val = E(2).val × E(3).val
The above grammar and the semantic rules are fed to
a Yacc tool (which is an LALR (1) parser generator)
for parsing and evaluating arithmetic expressions.
Which one of the following is true about the action of
Yacc for the given grammar?- (a)It detects recursion and eliminates recursion
- (b)It detects reduce-reduce conflict, and resolves
- (c)It detects shift-reduce conflict, and resolves the conflict in favor of a shift over a reduce action
- (d)It detects shift-reduce conflict, and resolves the conflict in favor of a reduce over a shift action
Self-check
Question 1
In the closure of , what is the lookahead of the new item ?
Show answerHide
Every terminal in FIRST(): FIRST(), and as well if can derive .
Question 2
The canonical LR(1) automaton of a grammar has 30 states which fall into 18 groups of equal cores. How many states does the LALR(1) parser have, and how many the SLR(1) parser?
Show answerHide
18 for LALR(1) (one per group) and 18 for SLR(1) (the same as the LR(0) automaton).
Question 3
Can merging LR(1) states into LALR(1) create a shift-reduce conflict?
Show answerHide
No. The shift entries depend only on the core, which is the same in the merged states, so a shift-reduce conflict after merging would already exist in one of the original states.
Question 4
Give a grammar that is LR(1) but not LALR(1).
Show answerHide
, , : merging the states after a c and b c gives a reduce-reduce conflict.
Revision card
One-screen revision
- LR(1) item = core + lookahead; closure uses FIRST(); reduce only on the item's lookahead.
- LALR(1): merge states with equal cores (union of lookaheads): same states as LR(0). May add reduce-reduce conflicts, never shift-reduce.
- Hierarchy LR(0) ⊂ SLR(1) ⊂ LALR(1) ⊂ LR(1); states LR(0) = SLR = LALR ≤ LR(1).
- : 7 and 10 states. Yacc is LALR(1).
References
- ·Aho, Lam, Sethi, Ullman, Compilers: Principles, Techniques, and Tools (2nd edition), Chapter 4 Syntax Analysis (4.7 more powerful LR parsers: canonical LR(1) items, constructing LR(1) sets of items, canonical LR(1) parsing tables, constructing LALR parsing tables)
- ·Cooper and Torczon, Engineering a Compiler, Chapter 3 Parsers (the LR(1) table construction, LALR(1) as merged LR(1))
Verification
LR(1) and LALR(1) item sets were built by script (scripts/cd_lib.py, class LR) and compared with a second implementation of the canonical LR(1) collection, and the LALR(1) lookaheads with the Dragon book's propagation algorithm, on eight grammars (scripts/enum-checks/cd_lr.py); the hierarchy LR(0) in SLR(1) in LALR(1) in LR(1) was checked on 1245 random reduced grammars with no violation; the state counts 7 / 10, 12 / 22 and the LR(1)-but-not-LALR(1) grammar are produced by this code. The theorem that merging cannot create a shift-reduce conflict is quoted with its short reason, not machine-proved. SECOND PASS (2026-11-02, done by the assistant, not a human check): every Self-check question was solved before the printed answer was read and all agreed; the definitions, worked examples, cheat box and traps were read claim by claim and the numbers re-derived by hand or by a small script (token counts, FIRST and FOLLOW sets, LL(1) tables and moves, LR item sets, state counts and parses, operator-precedence values, attribute evaluation and printing schemes, activation-record counts and access links, parameter-passing results, three-address code, jumping and backpatched code, leaders and blocks, value numbering and DAGs, gen/kill and data flow sets, Sethi-Ullman labels and live ranges); long C programs were not re-read line by line (they are compiled and compared by npm run verify:c, and their printed outputs were checked against the prose); tables and animations are machine output and were read, not re-run; No other defect found. Status raised to self-checked; verified needs a textbook or human check.
last verified: never
My notes (saved in this browser)