G27
Self-checkedTier 1 10 min readcd.parsing-ll1

Top-down parsing and LL(1)

Top-down parsing as a leftmost derivation, predictive parsing with a stack and a table, building the LL(1) table from FIRST and FOLLOW, the LL(1) condition and its common failures, a full parse trace, and error detection and recovery.

Why it exists

The simplest way to see whether a program fits the grammar is to try to build the parse tree from the top: start from the start symbol and keep expanding the leftmost nonterminal, matching terminals against the input. If, at every expansion, one token of lookahead is enough to know which production to use, no guessing and no backtracking is needed. Such grammars are LL(1), and the parser is fast, tiny, easy to write by hand (recursive descent) or to drive by a table, and gives good error messages.

Prerequisites

You need FIRST and FOLLOW (FIRST and FOLLOW) and a grammar without left recursion or common prefixes (transformations). The parser uses a stack (stack ADT).

Precise definitions

Top-down parsing. Constructing the parse tree from the root to the leaves, equivalently finding a leftmost derivation of the input. The tree grows by expanding the leftmost nonterminal.

LL(1). The first L: the input is read Left to right. The second L: the parser produces a Leftmost derivation. The 1: it uses one token of lookahead. An LL(1) grammar is one for which such a parser works without backtracking. An LL(kk) grammar uses kk tokens of lookahead; every LL(kk) grammar is unambiguous.

LL(1) condition. A grammar is LL(1) if and only if for every nonterminal AA with productions A→α1∣⋯∣αnA \to \alpha_1 \mid \dots \mid \alpha_n the sets SELECT(A→αi)\text{SELECT}(A \to \alpha_i) are pairwise disjoint, where for a production A→αA \to \alpha

SELECT=FIRST(α)∖{ε}  ∪  (FOLLOW(A) if ε∈FIRST(α)).\text{SELECT} = \text{FIRST}(\alpha) \setminus \{\varepsilon\} \ \ \cup \ \ \big(\text{FOLLOW}(A) \text{ if } \varepsilon \in \text{FIRST}(\alpha)\big).

Necessary conditions (not sufficient): not ambiguous, not left recursive, left factored. A grammar can pass all three and still fail LL(1), as the examples show.

The LL(1) parsing table M[A,a]M[A, a]. Rows are nonterminals, columns are terminals and \mathdollar\mathdollar. For every production A→αA \to \alpha and every a∈SELECT(A→α)a \in \text{SELECT}(A \to \alpha), put A→αA \to \alpha in M[A,a]M[A, a]. An empty cell means a syntax error. A cell with more than one production is a conflict: the grammar is not LL(1).

The parser (nonrecursive predictive parser). A stack of grammar symbols (with \mathdollar\mathdollar at the bottom and the start symbol on top) and the input followed by \mathdollar\mathdollar. Repeat with XX = top of stack and aa = next input token:

  1. X=a=\mathdollarX = a = \mathdollar: accept.
  2. XX a terminal: if X=aX = a, match: pop XX and advance the input; otherwise error.
  3. XX a nonterminal: if M[X,a]M[X, a] holds X→Y1⋯YkX \to Y_1 \cdots Y_k, output the production, pop XX and push Yk,…,Y1Y_k, \dots, Y_1 so that Y1Y_1 is on top (push nothing for ε\varepsilon); if M[X,a]M[X, a] is empty, error.

The sequence of productions output is the leftmost derivation. The tree is built by creating children for XX when it is expanded.

Error handling. The parser detects an error as soon as a terminal does not match or a table cell is empty; LL(1) parsers have the viable prefix property (they never shift a token that cannot continue a valid program), so the error is reported at the earliest possible token. Panic-mode recovery: when M[A,a]M[A, a] is empty, skip input tokens until one is found that is in a synchronising set of AA, typically FOLLOW(AA) (then pop AA and carry on) or FIRST(AA) (then expand AA as usual); the table cells for FOLLOW(AA) are filled with "synch". When a terminal on the stack does not match, pop it and issue a message (as if it had been inserted).

Recursive descent is the same method written as a procedure per nonterminal; it is a separate page. Power. LL(1) grammars are a proper subset of the LR(1) grammars (comparison of parsers); there are deterministic context-free languages with no LL(kk) grammar for any kk, for example {anbn}∪{ancn}\{a^n b^n\} \cup \{a^n c^n\} (the choice between the two forms depends on a symbol after an unbounded number of aa's).

How it works

Step through the parse of id+id∗id\text{id} + \text{id} * \text{id} with the expression grammar. The top of the stack is at the left. The table at the right shows the entry consulted each time (outlined); the tree grows at the left (new nodes shaded, nodes still on the stack dashed). Notice the pattern: a nonterminal on top is expanded using the table, a terminal on top is matched against the input, and the empty productions are chosen when the lookahead is something that may follow (++, ) or \mathdollar\mathdollar).

LL(1) parse of id + id * id: start

Parser run by a script, not typed

Predictive (table-driven LL(1)) parsing: stack with the top at the left; the parser traces a leftmost derivation.

  1. 1E → T E'
  2. 2E' → + T E'
  3. 3E' → ε
  4. 4T → F T'
  5. 5T' → * F T'
  6. 6T' → ε
  7. 7F → ( E )
  8. 8F → id
stack (top at the left)
E$
input
id+id*id$
action start
parse tree so far
E
parsing table M[A, a]
+*()id$
EE→T E'E→T E'
E'E'→+ T E'E'→εE'→ε
TT→F T'T→F T'
T'T'→εT'→* F T'T'→εT'→ε
FF→( E )F→id

Step 0

The stack holds the start symbol E above the end marker $; the input is followed by $. The rule: look at the top of the stack and the next input symbol. A terminal on top must match the input; a nonterminal on top is replaced using the table entry for (top, input).

0 / 17
computed by script: the algorithm is executed, one move per step. python3 scripts/gen-cd-traces.py

The table itself is built production by production from FIRST and FOLLOW:

Building the LL(1) table of the expression grammar: start

Computed by a script, not typed
  1. 1E → T E'
  2. 2E' → + T E'
  3. 3E' → ε
  4. 4T → F T'
  5. 5T' → * F T'
  6. 6T' → ε
  7. 7F → ( E )
  8. 8F → id
M[A, a]+*()id$
E
E'
T
T'
F

Step 0

For each production A → α: for every terminal a in FIRST(α) put the production in row A, column a; if α can vanish (ε in FIRST(α)) put it in every column b of FOLLOW(A) as well. A cell that receives two productions is a conflict: the grammar is not LL(1).

0 / 9
computed by script: the algorithm is executed, one move per step. python3 scripts/gen-cd-traces.py

When two productions land in the same cell the grammar is not LL(1). The dangling-else grammar (after left factoring) is the standard example: the lookahead e selects both S′→eSS' \to e S (by FIRST) and S′→εS' \to \varepsilon (because e can follow S′S').

The dangling-else grammar is not LL(1): start

Computed by a script, not typed
  1. 1S → i E t S S'
  2. 2S → a
  3. 3S' → e S
  4. 4S' → ε
  5. 5E → b
M[A, a]itaeb$
S
S'
E

Step 0

For each production A → α: for every terminal a in FIRST(α) put the production in row A, column a; if α can vanish (ε in FIRST(α)) put it in every column b of FOLLOW(A) as well. A cell that receives two productions is a conflict: the grammar is not LL(1).

0 / 6
computed by script: the algorithm is executed, one move per step. python3 scripts/gen-cd-traces.py

Finally an error. For the input id+∗id\text{id} + * \text{id} the parser expands TT after the plus and finds the cell M[T,∗]M[T, *] empty: no production for TT can start with ∗*, and the error is reported at that token.

LL(1) parse of id + * id (a syntax error): start

Parser run by a script, not typed

Predictive (table-driven LL(1)) parsing: stack with the top at the left; the parser traces a leftmost derivation.

  1. 1E → T E'
  2. 2E' → + T E'
  3. 3E' → ε
  4. 4T → F T'
  5. 5T' → * F T'
  6. 6T' → ε
  7. 7F → ( E )
  8. 8F → id
stack (top at the left)
E$
input
id+*id$
action start
parse tree so far
E
parsing table M[A, a]
+*()id$
EE→T E'E→T E'
E'E'→+ T E'E'→εE'→ε
TT→F T'T→F T'
T'T'→εT'→* F T'T'→εT'→ε
FF→( E )F→id

Step 0

The stack holds the start symbol E above the end marker $; the input is followed by $. The rule: look at the top of the stack and the next input symbol. A terminal on top must match the input; a nonterminal on top is replaced using the table entry for (top, input).

0 / 8
computed by script: the algorithm is executed, one move per step. python3 scripts/gen-cd-traces.py

Worked examples

EX 1A table and a parse for a small grammar

Easy

S→aSb∣εS \to a S b \mid \varepsilon. FIRST(aSba S b) = {a}; FOLLOW(SS) = {b, $} and S→εS \to \varepsilon is chosen on that set. So M[S,a]=S→aSbM[S, a] = S \to a S b, M[S,b]=M[S,\mathdollar]=S→εM[S, b] = M[S, \mathdollar] = S \to \varepsilon. No cell has two productions: LL(1). Parse aabbaabb (stack top at the left):

stack        input    move
S $          aabb$    output S → a S b
a S b $      aabb$    match a
S b $        abb$     output S → a S b
a S b b $    abb$     match a
S b b $      bb$      output S → ε
b b $        bb$      match b
b $          b$       match b
$            $        accept

The productions output, S→aSbS \to aSb, S→aSbS \to aSb, S→εS \to \varepsilon, are the leftmost derivation S⇒aSb⇒aaSbb⇒aabbS \Rightarrow aSb \Rightarrow aaSbb \Rightarrow aabb.

EX 2Counting the moves and the table entries

Easy

For the expression grammar the parse of id+id∗id\text{id} + \text{id} * \text{id} takes 11 expansion moves (one per internal node of the tree besides terminals: E,T,F,T′,E′,T,F,T′,F,T′,E′E, T, F, T', E', T, F, T', F, T', E'), 5 matches (one per token), and then the accept: 16 moves before the accept. The table has 13 non-empty entries: row EE 2, row E′E' 3, row TT 2, row T′T' 4, row FF 2 (counted from the table above). Neither number is a formula; both come from running the parse.

EX 3Why is this grammar not LL(1)?

Medium

Test S→Aa∣bS \to A a \mid b, A→b∣εA \to b \mid \varepsilon. SELECT(S→AaS \to A a) = FIRST(AaA a) = {b} ∪ {a} (as AA is nullable) = {a, b}; SELECT(S→bS \to b) = {b}. They share bb: on lookahead bb the parser cannot tell whether to expand AA (and then get A→bA \to b) or use S→bS \to b. Not LL(1) (a FIRST/FIRST conflict hidden behind a nullable symbol). For AA itself: SELECT(A→bA \to b) = {b}, SELECT(A→εA \to \varepsilon) = FOLLOW(AA) = {a}: disjoint, so AA alone is fine.

EX 4Prefix and recursion problems show up in the table

Medium

(a) A→ab∣acA \to a b \mid a c: both productions are entered at M[A,a]M[A, a]: a conflict; left factoring (A→aA′A \to a A', A′→b∣cA' \to b \mid c) removes it. (b) E→E+T∣TE \to E + T \mid T: both alternatives start with FIRST(TT), so every token that starts TT gives a conflict in row EE, and the recursive-descent version would call itself forever. Left recursion removal is needed. (c) Even after both fixes, the dangling else still conflicts (the table above), because the grammar is ambiguous: ambiguity can never be LL(1).

EX 5A question in the usual shape

GATE level

For S→(S)S∣εS \to ( S ) S \mid \varepsilon: FIRST = {(, ε}, FOLLOW = {), $}, so M[S,(]=S→(S)SM[S, (] = S \to (S)S and M[S,)]=M[S,\mathdollar]=S→εM[S, )] = M[S, \mathdollar] = S \to \varepsilon: the grammar is LL(1). Parse (): stack S \mathdollarS\,\mathdollar, input ()$: output S→(S)SS \to (S)S; match (; SS on top with ): output S→εS \to \varepsilon; match ); SS on top with \mathdollar\mathdollar: output S→εS \to \varepsilon; accept. Statements to evaluate in such a question: "the grammar is LL(1)" (true), "it is ambiguous" (false, an LL(1) grammar never is), "the parser needs two tokens of lookahead" (false). To refute LL(1) you only need one cell with two productions; to prove it you must check every nonterminal.

Cheat box

Cheat box

  • LL(1): Left-to-right input, Leftmost derivation, 1 token lookahead. The tree is built top-down; the stack holds the predicted rest of the sentence.
  • Table: for A→αA \to \alpha, put it in M[A,a]M[A, a] for a∈a \in FIRST(α\alpha)∖ε, and for a∈a \in FOLLOW(AA) if α\alpha is nullable.
  • Moves: terminal on top, match; nonterminal on top, expand with the table; andand means accept; empty cell means error.
  • LL(1) grammars are unambiguous, not left recursive, left factored. Not sufficient.
  • Conflicts: FIRST/FIRST (including common prefixes and left recursion), FIRST/FOLLOW (nullable alternative).
  • Panic mode: skip tokens until a synchronising token, usually from FOLLOW.
  • Recursive descent is the hand-written form of the same parser.

Traps and GATE patterns

Connections

The table needs FIRST and FOLLOW and a grammar prepared by the transformations. Writing the parser as procedures gives recursive descent. The bottom-up alternative is shift-reduce parsing and LR; the two families are compared in the parser hierarchy. The semantic actions that compute values during parsing are in syntax-directed definitions.

PYQs

8 previous year questions from your book. I re-solved each one myself (6 by running or simulating, 2 by reasoning only); the book's key is shown next to my answer. All PYQs

GATE 2026 · MSQQ1 · page 256 of the book
Which of the following statements is/are true?
  • (a)LL(1) parser uses backtracking
  • (b)For a grammar to be LL(1), it must be left- recursive
  • (c)For a grammar to be LL(1), it must be left- factored
  • (d)The LL(1) parsers are more powerful than the SLR parsers
GATE 2025 · MSQQ4 · page 256 of the book
Consider two grammars G1 and G2 with the
production rules given below:

G1: S → if E then S | if E then S else S | a

       E → b

G2: S → if E then S | M

       M → if E then M else S | c

       E → b

where if, then, else, a, b, c are the terminals.

Which of the following option(s) is/are CORRECT?
  • (a)G1 is not LL(1) and G2 is LL(1).
  • (b)G1 is LL(1) and G2 is not LL(1).
  • (c)G1 and G2 are not LL(1).
  • (d)G1 and G2 are ambiguous.
GATE 2024 · Set 1 · MSQ · 1 markQ7 · page 257 of the book
Which of the following is/are Bottom-Up Parser(s)
  • (a)Shift-reduce Parser
  • (b)Predictive Parser
  • (c)LL(1) Parser
  • (d)LR Parser
GATE 2021 · MCQQ11 · page 257 of the book
Consider the following context-free grammar where
the set of terminals is {a,b,c,d,f}.
S→daT|Rf
T→aS|baT|ε
R→caTR|ε

          The following is a partially-filled LL(1) parsing table.

a
b
c
d
f
$
S

(1)
S →da T
(2)

T
T →a S
 T →ba T
(3)

T →ε
(4)
R

R →caTR

R →ε

Which one of the following choices represents the
correct combination for the numbered cells in the
parsing table ("blank" denotes that the corresponding
cell is empty)?

COMPILER DESIGN
  • (a)(1) S →Rf (2) S →Rf (3) T →ε (4) T →ε
  • (b)(1) blank (2) S →R (3) T →ε (4) T →ε
  • (c)(1) S →Rf (2) blank (3) blank (4) T →ε
  • (d)(1) blank (2) S →Rf (3) blank (4) blank
GATE 2015 · MCQQ25 · page 260 of the book
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
GATE 2012 · MCQQ31 · page 261 of the book
For the grammar below, a partial LL(1) parsing table
is also presented along with the grammar. Entries that
need to be filled are indicated as E1, E2 and E3. ε is
the empty string, $ indicates end of input, and |
separates alternate right hand sides of productions.

S → a A b B | b A a B | ε

A → S

B → S

      a
b
$
S
E 1
E 2
 S →ε
A
 A → S
 A → S
error
B
B →S
B →S
E3

The FIRST and FOLLOW sets for the non-terminals
A and B are:-

FIRST(A) = {a, b, ε} = FIRST(B)
  • (a)FOLLOW( A) = {a, b} FOLLOW(B) = {a, b, $}
  • (b)FIRST(A) = {a, b, ε} = FIRST(B) FOLLOW(A) = {a, b} FOLLOW(B) = ∅ COMPILER DESIGN
  • (c)FIRST(A) = {a, b, $} FIRST(B) = {a, b, ε} FOLLOW(A) = {a, b} FOLLOW(B) = {$}
  • (d)FIRST(A) = {a, b} = FIRST(B) FOLLOW(A) = {a, b} FOLLOW(B) = {a, b}
GATE 2012 · MCQQ32 · page 262 of the book
For the grammar below, a partial LL(1) parsing
table is also presented along with the grammar.
Entries that need to be filled are indicated as E1,
E2, and E3.  epsilon is the empty string, $ indicates
end of input, and, | separates alternate right hand
sides of productions.

S →a A b B | b A a B | ε

A →S

B → S

      a
b
$
S
E 1
E 2
 S →ε
A
 A → S
 A → S
error
B
B →S
B →S
E3

The appropriate entries for E1 , E2, E3 are:-
  • (a)E1: S → aAbB,A → S E2: S → bAaB,B→S E3: B → S
  • (b)E1: S → aAbB,S→ ε E2: S → bAaB,S → ε E3: S → ε
  • (c)E1: S → aAbB,S → ε E2: S → bAaB,S→ε E3: B → S
  • (d)E1: A → S,S →ε E2: B → S,S → ε E3: B →S
GATE 2010 · MCQ · 2 marksQ34 · page 263 of the book
The grammar : S → aSa|bS|c is:-
  • (a)LL(1) but not LR(1)
  • (b)LR(1) but not LL(1)
  • (c)Both LL(1) and LR(1)
  • (d)Neither LL(1) nor LR(1)

Self-check

Question 1

Give the LL(1) table of S→aSb∣εS \to a S b \mid \varepsilon.

Show answer

M[S,a]=S→aSbM[S, a] = S \to aSb; M[S,b]=M[S,\mathdollar]=S→εM[S, b] = M[S, \mathdollar] = S \to \varepsilon.

Question 2

An LL(1) parser has on its stack T′T' at the top and the next token is )). Under which condition does it pop T′T' silently?

Show answer

When M[T′,)]M[T', )] holds T′→εT' \to \varepsilon, which is the case because ) is in FOLLOW(T′T') in the expression grammar.

Question 3

Is any ambiguous grammar LL(1)?

Show answer

No. An LL(1) parser produces a unique leftmost derivation for every sentence, so the grammar has one tree per sentence.

Question 4

Why must left recursion be removed before LL(1) parsing?

Show answer

For A→Aα∣βA \to A\alpha \mid \beta the productions have intersecting FIRST sets (every token that can start β\beta selects both), and a parser would expand AA forever without consuming input.

Revision card

One-screen revision

  • Top-down, leftmost derivation, 1 lookahead; stack plus table M[A,a]M[A, a].
  • Entry rule: FIRST(α\alpha)∖ε, plus FOLLOW(AA) if α\alpha nullable.
  • Moves: match terminal, expand nonterminal (push right side reversed), accept on andand, error on empty cell.
  • LL(1) grammar: no cell with two productions; unambiguous, not left recursive, left factored (necessary only).
  • Recovery: skip to a synchronising token (FOLLOW).

References

  • ·Aho, Lam, Sethi, Ullman, Compilers: Principles, Techniques, and Tools (2nd edition), Chapter 4 Syntax Analysis (4.4 top-down parsing: recursive descent, FIRST and FOLLOW, LL(1) grammars, nonrecursive predictive parsing, error recovery)
  • ·Cooper and Torczon, Engineering a Compiler, Chapter 3 Parsers (top-down parsing, LL(1) table construction)

Verification

The parse animations are produced by a table-driven parser run by script (scripts/gen-cd-traces.py). scripts/enum-checks/cd_grammar.py checks the LL(1) verdict and table against the language itself (left-sentential forms and the strings derivable from every alternative), checks that the parser accepts exactly the strings of the expression language on 6000 random token strings (against a parse-tree counter for the equivalent left-recursive grammar) and that its output replays as a leftmost derivation; tests/cd-traces.test.ts re-simulates every move in TypeScript. The error-recovery description (panic mode with synchronising sets) follows the textbook; the shown error animation stops at the first error without recovery. 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