How do SLR, LALR and canonical LR(1) table constructions differ in state count and in which conflicts they avoid?

## Same automaton, three answers to one question Every one of these constructions builds the same underlying recognizer of viable stack contents — states that are sets of items, a rule with a position marker in it. Shifting is never in dispute between them. The only question they answer differently is: **on which lookahead tokens may a completed rule be reduced?** - **SLR(1)** answers with `FOLLOW(A)`: every token that can follow the nonterminal `A` **anywhere in the grammar**. Cheap, and deliberately context-blind. - **Canonical LR(1)** answers per item: each item carries its own lookahead set, derived from the context in which that item became reachable. - **LALR(1)** answers with the canonical lookaheads, but after merging every pair of states whose item cores are identical — the lookahead sets are unioned during the merge. ## The comparison that gets asked | Construction | States | Lookahead source | Characteristic failure | |---|---|---|---| | SLR(1) | the LR(0) count | global `FOLLOW` of the nonterminal | spurious conflicts in contexts where the follower cannot really occur | | LALR(1) | the LR(0) count | canonical lookaheads, unioned per core | a reduce-reduce conflict created by the merge | | Canonical LR(1) | many more; several times the LR(0) count is ordinary | exact per-item lookaheads | table size and generation cost | Grammar coverage nests strictly: every SLR(1) grammar is LALR(1), and every LALR(1) grammar is LR(1). There are grammars in each gap. ## What merging can and cannot break This is the precise claim worth remembering, in the right direction: 1. Merging two states with the same item core **can** produce a reduce-reduce conflict, because two complete items whose lookahead sets were disjoint in the separate states may overlap once unioned. 2. Merging **cannot** produce a shift-reduce conflict, because the shift actions come from the core, which both merged states already shared; unioning lookaheads adds reductions, never shifts. That asymmetry is why LALR is the practical default: the only thing you can lose by merging is a rare reduce-reduce case, and when you hit one, regenerating without the merge tells you immediately whether the rule set or the merge was at fault. ## Error behaviour, which is not the same thing There is a second, subtler difference that only shows on **invalid** input. Because merged lookaheads are a superset, a merged table may perform a few extra reductions before it notices an error. It never shifts a token that the exact construction would have rejected, so no invalid input is accepted — the error is announced at the same input position, just after some additional reductions. If diagnostics reconstruct the construct being parsed from the stack, those extra reductions can blur the message slightly. ## Choosing under real constraints - Start at the middle option. The merged construction gives near-exact lookaheads at the smallest table, which is why it is the common default. - Move up only on evidence: a reduce-reduce conflict that **disappears** when the states are kept apart was a merge artefact, not a grammar defect. - Do not move down. The context-blind construction's extra conflicts are noise: it rejects grammars that are perfectly deterministic, which costs grammar-rewriting effort to work around. - No construction rescues a rule set with two readings of the same text. If a conflict survives the exact construction, the rules mean two things and must be changed. ## The one-line summary Precision of lookahead versus number of states, with the merged construction sitting at the knee of that curve — nearly all of the precision, none of the state explosion, and one known failure mode you can test for in a single regeneration.