LL(1) Parser Table Explained: FIRST, FOLLOW and a Complete Worked Example
Build an LL(1) parsing table from one grammar, verify every cell, and follow the stack from S$ to acceptance. The same example connects FIRST, FOLLOW, conflicts and epsilon moves.
KnowledgeGate Team
Exam prep & CS education

FIRST and FOLLOW sets are only the setup. In the balanced-parentheses grammar below, the same nullable start symbol recurs inside and after a matched pair, so the table must guide every move through ()()$. The earlier LL(1) Parsing Table Construction: Worked GATE Example is the faster cell-filling drill with a sequence grammar. Balanced parentheses instead force the finished table to decide both recursive expansion and the epsilon moves in a complete acceptance trace.
LL(1) parser: what the two Ls and the 1 mean
The first L means scanning input from left to right, the second means constructing a leftmost derivation, and 1 means using one lookahead token.
An LL(1) parser is predictive: (nonterminal on stack, lookahead token) must select exactly one production. This is predictive top-down parsing in table-driven form. Recursive descent puts similar choices in hand-written functions instead.
Its three working parts are:
input ending in
$;a stack starting with
S$;table
M[A, a]for nonterminalAand lookaheada.
The stack top is written on the left throughout. A terminal match consumes input. A lookup replaces a nonterminal with its selected right-hand side. $ against $ accepts.
FIRST and FOLLOW rules that fill an LL(1) table
For A -> alpha, put the production in M[A, t] for every terminal t in FIRST(alpha). If epsilon is in FIRST(alpha), also put the production in M[A, b] for every b in FOLLOW(A). epsilon is never a table column because it is not an input token.
Use this grammar, with start symbol S and terminals {(, )}:
S -> (S)S | epsilonThe production S -> (S)S creates one matched pair. Its first recursive S generates the material inside that pair, while the second generates any balanced sequence after it. The epsilon alternative ends either role. The grammar therefore generates strings such as (), (()) and ()(), but not )( or an unmatched parenthesis.
The FIRST set is:
FIRST((S)S) = {(}because the right-hand side begins with the terminal(.FIRST(epsilon) = {epsilon}. ThereforeFIRST(S) = {(, epsilon}.
The FOLLOW set is:
$is inFOLLOW(S)becauseSstarts the grammar.)is inFOLLOW(S)because the firstSin(S)Sis followed by). The trailingSinherits the left-hand side follow set but adds no new symbol. ThusFOLLOW(S) = {), $}.
For a longer fixed-point computation with several nonterminals, practise First and Follow in Compiler Design: Solved Examples.
LL(1) grammar test: find conflicts before building the parser
The non-epsilon alternative has FIRST((S)S) = {(}. The nullable alternative must use FOLLOW(S) = {), $}. Their intersection is empty, so one lookahead token always distinguishes expansion from disappearance.
Operationally, M[S,(] receives S -> (S)S, while M[S,)] and M[S,$] receive S -> epsilon. No cell receives both productions, so the grammar is LL(1).
FIRST/FIRST conflicts join two non-epsilon alternatives on one lookahead. FIRST/FOLLOW conflicts let a nullable alternative compete with another production on a following token. A collision, not an empty cell, rejects an LL(1) grammar.
For example, if X -> a | epsilon and a is in FOLLOW(X), both productions enter M[X,a]. That multiply defined cell proves the grammar is not LL(1).
LL(1) parsing table construction, cell by cell
From FIRST((S)S) = {(}, place S -> (S)S in M[S,(]. Because the other alternative is nullable, use FOLLOW(S) = {), $} to place S -> epsilon in M[S,)] and M[S,$].
Nonterminal |
|
|
|
|---|---|---|---|
|
|
|
|
Those are all possible cells because the grammar has one nonterminal and three input columns. The table is complete, and its single row makes the decision visible: expand on (; disappear before ) or $.
LL(1) parser trace for ()()$
The stack top stays on the left. A terminal match consumes input, while an epsilon production removes S without consuming anything.
Stack | Remaining input | Action |
|---|---|---|
|
| use |
|
| match |
|
| use |
|
| match |
|
| use |
|
| match |
|
| use |
|
| match |
|
| use |
|
| accept |
At each closing parenthesis, M[S,)] selects S -> epsilon so the parser can match ). After the second pair, M[S,$] removes the final trailing S. Only then does $ meet $ and accept. The trace shows that the two FOLLOW-based entries perform different jobs even though they contain the same production.
LL(1) parser table mistakes and how to repair them
Creating an epsilon column.
epsiloncannot appear in the input. PutS -> epsilonunderFOLLOW(S), which gives the)and$columns here.Using FIRST(S) for every alternative. Compute
FIRST((S)S)andFIRST(epsilon)separately. Each production enters cells from its own right-hand side; the nullable one then usesFOLLOW(S).Pushing a production in the wrong order. With the stack top on the left, replacing
Sby(S)Smust leave(on top. If your convention puts the top on the right, push the right-hand side in reverse order and keep that convention throughout.Assuming epsilon always causes a conflict. A nullable alternative is safe when its competing FIRST symbols do not overlap the left-hand side FOLLOW set. Inspect the actual table cells rather than rejecting epsilon by itself.
Before table construction, eliminate immediate left recursion such as E -> E + T | T, and left-factor common prefixes such as E -> id | id + E.
How GATE tests LL(1) parser tables
The official GATE 2024 CS Set 2 paper, Q40, archived on the official GATE 2025 IIT Roorkee portal, gives a grammar with epsilon-productions and a partly filled LL(1) table. It asks which productions or blanks complete numbered cells.
Other questions ask you to compute FIRST and FOLLOW, test whether a grammar is LL(1), locate conflicts, complete entries, or trace acceptance. Make one table and one stack trace by hand because set-only work misses the complete procedure.
LL(1) selects productions top down with one lookahead. LR-family parsers use states and ACTION/GOTO tables. SLR vs CLR vs LALR Parsers for GATE: States and Conflicts develops that bottom-up comparison.
LL(1) parser table: the short version and next step
Use this five-step checklist:
Remove left recursion and left-factor the grammar if needed.
Compute FIRST for each right-hand side.
Compute FOLLOW for every nonterminal.
Fill the table, allowing only one production per cell.
Trace stack and input until
$meets$, or an error occurs.
The balanced-parentheses grammar is LL(1), its table has no collisions, and ()()$ is accepted. For the wider route, explore GATE CS Exam Preparation. For structured Compiler Design coverage within broader preparation, use GATE Guidance by Sanchit Sir.
Now rebuild the table without looking. Then trace (())$ as a self-check: expand on both opening parentheses, use M[S,)] twice before matching the outer closing parenthesis, and finish with M[S,$] before accept.
Keep learning

Intermediate Code Generation in Compiler Design: TAC, Backpatching and DAGs
Connect expressions, short-circuit control flow and local optimisation through a single worked translation, from source code to resolved TAC and a reusable DAG.

Ambiguous Grammars and Inherent Ambiguity: Worked CFG Examples for GATE
Learn what two derivations really prove, resolve expression ambiguity with precedence, and trace the classic inherently ambiguous language through aabbcc.

Simplification of CFG: Remove Epsilon, Unit and Useless Productions Step by Step
Simplify one context-free grammar from nine nonterminals to six. See each intermediate grammar, complete unit closures, symbol checks and final derivations.

Phases of Compiler Explained: Worked Example from Tokens to Target Code
Follow one four-line program through lexical, syntax and semantic analysis, then see its intermediate code optimized to a final stored value of 24.0.