A parser generator reports a reduce/reduce conflict in the LALR(1) parser for a grammar that had no conflicts in the canonical LR(1) parser. What is the most likely explanation?
AThe grammar is inherently ambiguous — both parsers should have reported the conflict
BLALR merging combined the lookahead sets of two LR(1) states that shared a core, creating ambiguity about which reduction to apply in the merged state
CThe parser generator has a bug; LALR and LR(1) must agree on all conflicts for any grammar
DThe conflict is a shift/reduce conflict that LALR reports differently than LR(1)
This is exactly the power loss that LALR(1) incurs compared to canonical LR(1). Two LR(1) states with identical cores but different lookahead sets are merged into a single LALR state whose lookahead set is the union of both. If those original states would have used different reductions on tokens that are now combined in the merged lookahead set, a reduce/reduce conflict appears. Importantly, this is never a shift/reduce conflict — merging states can only introduce reduce/reduce conflicts, never shift/reduce ones, because shift decisions depend on the core (which is identical), not the lookahead.
Question 2 Multiple Choice
What specifically does LALR(1) merge compared to canonical LR(1), and what is the primary practical benefit?
ALALR merges any two states whose actions agree, reducing table size at the cost of accepting slightly fewer grammars
BLALR merges LR(1) states that have identical cores (same set of dotted productions) but possibly different lookahead sets, dramatically reducing the number of states to near SLR-level compactness
CLALR merges shift and reduce actions into combined entries, reducing memory usage in the action table
DLALR merges grammars with identical start symbols, allowing multiple grammars to share a single parser
The key insight of LALR construction: LR(1) creates separate states for configurations that differ only in lookahead, which can produce thousands of states for a real language. LALR identifies states with the same core (same set of LR(0) items, regardless of lookahead annotation) and merges them, combining their lookahead sets. The result is a parser with roughly the same number of states as SLR — far fewer than canonical LR(1) — but more powerful than SLR because the merged lookaheads are more precise than FOLLOW sets.
Question 3 True / False
Merging states in LALR construction can introduce shift/reduce conflicts that would not exist in the canonical LR(1) parser for the same grammar.
TTrue
FFalse
Answer: False
False — and this is a critical property of LALR that makes it useful. Merging states with identical cores can only introduce reduce/reduce conflicts, never shift/reduce conflicts. This is because shift decisions depend on which token is in the input and what state the core puts us in — both determined by the core, which is identical in the merged states. Shift/reduce conflicts that appear in LALR reflect a genuine problem in the grammar or its canonical LR(1) parser as well; LALR did not create them.
Question 4 True / False
LALR(1) parsers handle virtually all programming language grammars used in practice, making them the default choice in tools like Yacc and Bison despite being theoretically less powerful than canonical LR(1).
TTrue
FFalse
Answer: True
True. While LALR(1) is strictly less expressive than canonical LR(1) — there exist LR(1) grammars that are not LALR(1) — such grammars are extremely rare in practice. Real programming language grammars designed for use with parser generators are almost invariably LALR(1). The practical payoff is enormous: LALR parsers require far fewer states (hundreds instead of thousands), making them faster and easier to implement and maintain. This tradeoff of a tiny theoretical loss for massive practical gain is why Yacc, Bison, and most industrial parser generators default to LALR(1).
Question 5 Short Answer
Explain why LALR(1) can sometimes produce reduce/reduce conflicts that canonical LR(1) would not have, and why this rarely matters in practice.
Think about your answer, then reveal below.
Model answer: LALR(1) merges LR(1) states that share the same core but differ in lookahead sets. In the merged state, the lookaheads are the union of the originals. If the original states used different reductions on tokens that now appear together in the merged set, the merged state cannot determine which reduction to apply — a reduce/reduce conflict. LR(1) avoided this by keeping those states separate. In practice, grammars where this matters are very rare; real language grammars are almost always designed to be LALR(1) clean.
The conceptual point is that LALR trades some theoretical expressiveness for practical compactness. The 'lost' grammars are pathological edge cases that rarely arise when designing a real language. When LALR does report a reduce/reduce conflict that LR(1) would not, the fix is usually to refactor the grammar slightly — an easier solution than switching to the far more expensive canonical LR(1) parser. This is why understanding what LALR merging does helps you diagnose and fix conflicts rather than just accepting them as mysterious errors from the parser generator.