chap. 5, top-down parsing j. h. wang mar. 29, 2011
TRANSCRIPT
Chap. 5, Top-Down Parsing
J. H. WangMar. 29, 2011
Outline
• Overview• LL(k) Grammars• Recursive-Descent LL(1) Parsers• Table-Driven LL(1) Parsers• Obtaining LL(1) Grammars• A Non-LL(1) Language• Properties of LL(1) Parsers• Parse Table Representation• Syntactic Error Recovery and Repair
Overview
• Two forms of top-down parsers– Recursive-descent parsers– Table-driven LL parsers: LL(k) – to be explained
later
• Compiler compilers (or parser generators)– CFG as a language’s definition, parsers can be
automatically constructed– Language revision, update, or extension can be
easily applied to a new parser– Grammar can be proved unambiguous if parser
construction is successful
Top-Down Parsing
• Top-down– To grow a parse tree from root to leaves
• Predictive– Must predict which production rule to be
applied
• LL(k)– Scan input left to right, leftmost derivation, k
symbol lookahead
• Recursive descent– Can be implemented by a set of mutually
recursive procedures
LL(k) Grammars
• Recall from Chap.2– A parsing procedure for each nonterminal A– The procedure is responsible for
accomplishing one step of derivation for the corresponding production
– Choosing production by inspecting the next k tokens. Predict Set for production A is the set of tokens that trigger the production
– Predict Set is determined by the right-hand side (RHS)
• We need a strategy for choosing productions– Predictk(p): the set of length-k token strings
that predict the application of rule p• Input string: a*
• S=>*lmAy1…yn
– P={pProductionsFor(A)|aPredict(p)}• P: empty set -> syntax error• P: more than one productions -> nondeterminism• P: exactly one production
How to Compute Predict(p)
• To predict production p: AX1…Xm, m>=0– The set of terminal symbols that are first
produced in some derivation from X1…Xm
– Those terminal symbols that can follow A
– (Fig. 5.1)
• For LL(1) grammar, the productions for each nonterminal A must have disjoint predict sets
• Not all CFGs are LL(1)– More lookahead may be needed: LL(k),
k>1– A more powerful parsing method may
be required (Chap. 6)– The grammar may be ambiguous
S
MATCH
PEEK
ADVANCE
ERROR
Recursive-Descent LL(1) Parsers
• Input: token stream ts– PEEK(): to examine the next input token
without advancing the input– ADVANCE(): to advances the input by one
token
• To construct a recursive-descent parser– We write a separate procedure for each
nonterminal A– For each production pi, we check each symbol
in the RHS X1…Xm
• Terminal symbol: MATCH(ts, Xi)• Nonterminal symbol: call Xi(ts)
PEEK
PEEK
PEEK
PEEK
PEEK
PEEK
PEEK
PEEK
PEEK
PEEK
PEEK
MATCH
MATCH
MATCH
MATCH
MATCH
MATCH
Table-Driven LL(1) Parsers
• Creating recursive-descent parsers can be automated, but– Size of parser code– Inefficiency: overhead of method calls and
returns
• To create table-driven parsers, we use stack to simulate the actions by MATCH() and calls to nonterminals’ procedures– Terminal symbol: MATCH– Nonterminal symbol: table lookup– (Fig. 5.8)
PUSH
MATCH
POP
ERROR
APPLY
APPLY
POP
PUSH
PEEK
PARSER
How to Build LL(1) Parse Table
• The table is indexed by the top-of-stack (TOS) symbol and the next input token– Row: nonterminal symbol– Column: next input token– (Fig. 5.9)
ILL ABLE
Obtaining LL(1) Grammars
• It’s easy to violate the requirement of a unique prediction for each combination of nonterminal and lookahead symbols– Common prefixes– Left recursion
Common Prefixes
• Two productions for the same nonterminal begin with the same string of grammar symbols– Ex. (Fig. 5.12) Not LL(k)
• Factoring transformation– Fig. 5.13– Ex. (Fig. 5.14)
ACTOR
LIMINATE EFT ECURSION
Left Recursion
• A production is left recursive if its LHS symbol is also the first symbol of its RHS– E.g. StmtList StmtList ; Stmt– AA
| – (Fig. 5.15 & Fig. 5.16)
A Non-LL(1) Language
• Almost all common programming language constructs: LL(1)– One exception: if-then-else (dangling
else program)– Can be resolved by mandating that each
else is matched to its closest unmatched then
– (Fig. 5.17)
• Ambiguous (Chap. 6)– E.g. if expr then if expr then other else
other• If expr then { if expr then other else other }• If expr then { if expr then other } else other• -> at least two distinct parses
• Dangling bracket language (DBL)– DBL={[i]j|i≥j≥0}
• if expr then Stmt -> [ (opening bracket)• else Stmt -> ] (optional closing bracket)
• Fig. 5.18(a)– S [ S CL
| λCL ] | λ
• E.g. [[]
• Fig. 5.18(b)– S [ S
| TT [ T ] | λ
• It’s not LL(k)– [Predict( S[S )
[Predict( ST )[[Predict2( S[S )[[Predict2( ST )…[kPredictk( S[S )[kPredictk( ST )
Properties of LL(1) Parsers
• A correct, leftmost parse is constructed
• All grammars in LL(1) are unambiguous
• All table-driven LL(1) parsers operate in linear time and space with respect to the length of the parsed input
Thanks for Your Attention!