Compiler Design

Lecture 6: Syntax Analysis (Parsing) II

Agenda
1. Parse Tree
2. Abstract Syntax Tree
3. Ambiguous grammars
4. Dangling Else

Sahar Selim CSCI415 | Compiler Design Lecture 6: Syntax Analysis II 2

1 Derivations & Parse Trees

Sahar Selim CSCI415 | Compiler Design Lecture 6: Syntax Analysis II 3

 Parsing Tree
A parse tree is a tree encoding the steps in a
derivation.
 Each internal node is labeled with a nonterminal.
 Each leaf node is labeled with a terminal.
 Reading the leaves from left to right gives the
string that was produced.

 The children of each internal node represent the replacement of

the associated non-terminal in one step of the derivation.

Sahar Selim CSCI415 | Compiler Design Lecture 6: Syntax Analysis II 4

Parse Tree
A leftmost derivation is a derivation in which
each step expands the leftmost nonterminal
(corresponds to preorder).

A rightmost derivation is a derivation in which

each step expands the rightmost nonterminal
(corresponds to postorder).

Sahar Selim CSCI415 | Compiler Design Lecture 6: Syntax Analysis II 5

Parsing Tree

 Left most derivation

（ 1 ） exp => exp op exp
（2） => number op exp
（3） => number + exp
（4） => number + number

 Right most derivation

(1) exp => exp op exp
(2) => exp op number
(3) => exp + number
(4) => number + number

Sahar Selim CSCI415 | Compiler Design Lecture 6: Syntax Analysis II 6

Parsing Tree
 Neither leftmost nor rightmost derivation
（ 1 ） exp => exp op exp
（2） => exp + exp
（3） => number + exp
（4） => number + number
 Generally, a parse tree corresponds to many derivations
 represent the same basic structure for the parsed string of
terminals.
 It is possible to distinguish particular derivations that are
uniquely associated with the parse tree.

Sahar Selim CSCI415 | Compiler Design Lecture 6: Syntax Analysis II 7

Derivations
 Derivations do not uniquely represent the
structure of the strings
 There are many derivations for the same string.
Example: exp  exp op exp | (exp) | number
op  + | – | *
 The string of tokens:
(number - number ) * number
 There exists two different derivations for above
string
Sahar Selim CSCI415 | Compiler Design Lecture 6: Syntax Analysis II 8
 Derivation steps use a different

Rightmost Derivations arrow (=>) from the arrow meta-

symbol in the grammar rules ().
exp  exp op exp | (exp) | number
(number - number ) * number op  + | – | *

(1) exp => exp op exp [exp  exp op exp]

(2)=> exp op number [exp  number]
(3)=> exp * number [op  * ]
(4) => ( exp ) * number [exp  ( exp ) ]
(5) =>( exp op exp ) * number [exp  exp op exp]
(6)=> (exp op number) * number [exp  number]
(7)=> (exp - number) * number [op  - ]
(8)=> (number - number) * number [exp  number]

Sahar Selim CSCI415 | Compiler Design Lecture 6: Syntax Analysis II 9

Leftmost Derivations
exp  exp op exp | (exp) | number
(number - number ) * number op  + | – | *

(1) exp => exp op exp [exp  exp op exp]

(2)=> (exp) op exp [exp  ( exp )]
(3)=> (exp op exp) op exp [exp  exp op exp]
(4) => (number op exp) op exp [exp  number]
(5) =>(number - exp) op exp [op  - ]
(6)=> (number - number) op exp [exp  number]
(7)=> (number - number) * exp [op  *]
(8)=>(number - number) * number [exp  number]
Sahar Selim CSCI415 | Compiler Design Lecture 6: Syntax Analysis II 10
Parsing Tree
 The example:
 exp => exp op exp => number op exp => number + exp
=> number + number
 Corresponding to the parse tree:
exp

exp op exp

number + number

Sahar Selim CSCI415 | Compiler Design Lecture 6: Syntax Analysis II 12

Parsing Tree
 The parse tree corresponds to the first derivation
(Left-most).
1 exp

2 exp 3 op 4 exp

number + number

Sahar Selim CSCI415 | Compiler Design Lecture 6: Syntax Analysis II 13

Example: The expression (34-3)*42
 The parse tree for the above arithmetic expression
1 exp

4 exp 3 op 2 exp
Right-most
( 5 exp ) * number Derivation

8 exp 7 op 6 exp

number – number
Sahar Selim CSCI415 | Compiler Design Lecture 6: Syntax Analysis II 14
Parse Trees:
int * ( int + int)

Sahar Selim CSCI415 | Compiler Design Lecture 6: Syntax Analysis II 15

Parse Trees:
int * ( int + int)

Sahar Selim CSCI415 | Compiler Design Lecture 6: Syntax Analysis II 16

Parse Trees:
int * ( int + int)

Sahar Selim CSCI415 | Compiler Design Lecture 6: Syntax Analysis II 17

Parse Trees:
int * ( int + int)

Sahar Selim CSCI415 | Compiler Design Lecture 6: Syntax Analysis II 18

Parse Trees:
int * ( int + int)

Sahar Selim CSCI415 | Compiler Design Lecture 6: Syntax Analysis II 19

Parse Trees:
int * ( int + int)

Sahar Selim CSCI415 | Compiler Design Lecture 6: Syntax Analysis II 20

Parse Trees:
int * ( int + int)

Sahar Selim CSCI415 | Compiler Design Lecture 6: Syntax Analysis II 21

Parse Trees:
int * ( int + int)

Sahar Selim CSCI415 | Compiler Design Lecture 6: Syntax Analysis II 22

Parse Trees:
int * ( int + int)

Sahar Selim CSCI415 | Compiler Design Lecture 6: Syntax Analysis II 23

Parse Trees:
int * ( int + int)

Sahar Selim CSCI415 | Compiler Design Lecture 6: Syntax Analysis II 24

Parse Trees:
int * ( int + int)

Sahar Selim CSCI415 | Compiler Design Lecture 6: Syntax Analysis II 25

Parse Trees:
int * ( int + int)

Sahar Selim CSCI415 | Compiler Design Lecture 6: Syntax Analysis II 26

Parse Trees:
int * ( int + int)

Sahar Selim CSCI415 | Compiler Design Lecture 6: Syntax Analysis II 27

Parse Trees:
int * ( int + int)

Sahar Selim CSCI415 | Compiler Design Lecture 6: Syntax Analysis II 28

Parse Trees:
int * ( int + int)

Sahar Selim CSCI415 | Compiler Design Lecture 6: Syntax Analysis II 29

Parse Trees:
int * ( int + int)

Sahar Selim CSCI415 | Compiler Design Lecture 6: Syntax Analysis II 30

Parse Trees:
int * ( int + int)

Sahar Selim CSCI415 | Compiler Design Lecture 6: Syntax Analysis II 31

Parse Trees:
int * ( int + int)

Sahar Selim CSCI415 | Compiler Design Lecture 6: Syntax Analysis II 32

A Serious Problem

Ambiguous Grammar

Sahar Selim CSCI415 | Compiler Design Lecture 6: Syntax Analysis II 33

Parse Trees (Recap)
 Goal of syntax analysis:
 Recover the structure described by a series of tokens.
 If language is described as a CFG, goal is to recover a parse
tree for the input string.
A parse tree is a tree, encoding the steps in a derivation.
 Internalnodes represent nonterminal symbols used in the
production.
 In order walk of the leaves contains the generated string.
 Encodes what productions are used, NOT the order in which
those productions are applied.
Sahar Selim CSCI415 | Compiler Design Lecture 6: Syntax Analysis II 34
2 Abstract Syntax Trees

Sahar Selim CSCI415 | Compiler Design Lecture 6: Syntax Analysis II 35

Why Abstract Syntax-Tree ?

 The parse tree contains more information

than is absolutely necessary for a compiler
 For the example: 3*4
exp

exp op exp

number * number
(3) (4)
Sahar Selim CSCI415 | Compiler Design Lecture 6: Syntax Analysis II 36
Why Abstract Syntax-Tree ?
 The principle of syntax-directed translation
 The meaning, or semantics, of the string 3+4 should be directly
related to its syntactic structure as represented by the parse tree.
 In this case, the parse tree should imply that the value 3 and
the value 4 are to be added.
 A much simpler way to represent this same information,
namely, as the tree
+

3 4

Sahar Selim CSCI415 | Compiler Design Lecture 6: Syntax Analysis II 37

Tree for expression (34-3)*42
 The expression (34-3)*42 whose parse tree can be
represented more simply by the tree:
*

- 42

34 3
 The parentheses tokens have actually disappeared
 still represents precisely the semantic content of
subtracting 3 from 34, and then multiplying by 42

Sahar Selim CSCI415 | Compiler Design Lecture 6: Syntax Analysis II 38

Example 1
 The grammar for simplified if-statements

statement  if-stmt | other

if-stmt  if ( exp ) statement
| if ( exp ) statement else statement
exp  0 | 1

Sahar Selim CSCI415 | Compiler Design Lecture 6: Syntax Analysis II 39

Example 1
statement  if-stmt | other
 The parse tree for the string: if-stmt  if ( exp ) statement
| if ( exp ) statement else statement
 if (0) other else other exp  0 | 1
statement

if-stmt

if ( exp ) statement else statement

0 other other
Sahar Selim CSCI415 | Compiler Design Lecture 6: Syntax Analysis II 40
Example 2
 Using another grammar of if-statement

statement  if-stmt | other

if-stmt  if ( exp ) statement else-part
else-part  else statement | 
exp  0 | 1

Sahar Selim CSCI415 | Compiler Design Lecture 6: Syntax Analysis II 41

Example 2
 This same string has the following parse tree:
 if (0) other else other statement  if-stmt | other
statement if-stmt  if ( exp ) statement else-part
else-part  else statement | 
if-stmt exp  0 | 1

if ( exp ) statement else-part

0 other else statement

other
Sahar Selim CSCI415 | Compiler Design Lecture 6: Syntax Analysis II 42
Example 3
 The grammar of a sequence of statements
separated by semicolons:

stmt-sequence  stmt ; stmt-sequence| stmt

stmt  s

Sahar Selim CSCI415 | Compiler Design Lecture 6: Syntax Analysis II 43

Example 3
 The string s; s; s has the following parse tree with
respect to this grammar: stmt-sequence  stmt ; stmt-sequence| stmt
stmt-sequence stmt  s

stmt ; stmt-sequence

s stmt ; stmt-sequence

s stmt

s
Sahar Selim CSCI415 | Compiler Design Lecture 6: Syntax Analysis II 44
Example 3

 A possible syntax tree for this same string is:

;

s ;

s s

 Bind all the statement nodes in a sequence together with just

one node, so that the previous syntax tree would become
seq

s s s

Sahar Selim CSCI415 | Compiler Design Lecture 6: Syntax Analysis II 45

Parse tree vs Syntax tree

Sahar Selim CSCI415 | Compiler Design Lecture 6: Syntax Analysis II 46

 Parse Tree Syntax Tree
Interior  nodes are  non-terminals, Interior nodes are “operators”, leaves
leaves are terminals are operands
Rarely constructed as a data When representing a program in a tree
structure structure usually use a syntax tree
Represents the concrete syntax of a Represents the abstract syntax of a
program program (the semantics)
Contains unusable information also Contains only meaningful information
Grammar: E → E * E | E + E | id
Program: a + b * c

Sahar Selim CSCI415 | Compiler Design Lecture 6: Syntax Analysis II 47

48
3 Ambiguity

Sahar Selim CSCI415 | Compiler Design Lecture 6: Syntax Analysis II 49

A Serious Problem (Recap)

Ambiguous Grammar

Sahar Selim CSCI415 | Compiler Design Lecture 6: Syntax Analysis II 50

Ambiguity
A CFG is said to be ambiguous if there is at least
one string with two or more parse trees.
 Note that ambiguity is a property of grammars,
not languages:
 there can be multiple grammars for the same
language, where some are ambiguous and some aren't.
 Some languages are inherently ambiguous:
 there are no unambiguous grammars for those
languages.
Sahar Selim CSCI415 | Compiler Design Lecture 6: Syntax Analysis II 51
 What is Ambiguity?
This string has two different parse trees.

exp exp

exp op exp exp op exp

_ exp op exp
* number
exp op exp number
number * number
number - number

Sahar Selim CSCI415 | Compiler Design Lecture 6: Syntax Analysis II 52

What is Ambiguity?
Corresponding to the two leftmost derivations

exp => exp op exp exp => exp op exp

=> exp op exp op exp , => number op exp
=> number - exp
=> number op exp op exp => number - exp op exp
=> number - exp op exp => number - number op exp
=> number - number op exp => number - number * exp
=> number - number * number
=> number - number * exp
=> number - number * number

Sahar Selim CSCI415 | Compiler Design Lecture 6: Syntax Analysis II 53

What is Ambiguity?

The associated syntax trees are

*

- 42

34 3 AND
-

34 *

3 42

Sahar Selim CSCI415 | Compiler Design Lecture 6: Syntax Analysis II 54

Resolving

Sahar Selim CSCI415 | Compiler Design Lecture 6: Syntax Analysis II 55

Resolving Ambiguity
 Designing unambiguous grammars is tricky and
requires planning from the start.
 It's hard to start with an ambiguous grammar and
to manually massage it into an unambiguous one.
 Often, have to throw the whole thing out and
start over.

Sahar Selim CSCI415 | Compiler Design Lecture 6: Syntax Analysis II 56

Resolving Ambiguity
 We have just seen that this grammar is
ambiguous:
E → E Op E | int
Op → + | - | * | /
Goals
 Eliminate the ambiguity from the grammar
 Make the only parse trees for the grammar the ones
corresponding to operator precedence
Sahar Selim CSCI415 | Compiler Design Lecture 6: Syntax Analysis II 57
Operator Precedence
 Can often eliminate ambiguity from grammars with
operator precedence issues by building
precedencies into the grammar.
 Since * and / bind more tightly than + and -, think of
an expression as a series of “blocks” of terms
multiplied and divided together joined by +s and -s.

Sahar Selim CSCI415 | Compiler Design Lecture 6: Syntax Analysis II 58

Operator Precedence
 Can often eliminate ambiguity from grammars with
operator precedence issues by building
precedencies into the grammar.
 Since * and / bind more tightly than + and -, think of
an expression as a series of “blocks” of terms
multiplied and divided together joined by +s and -s.

Sahar Selim CSCI415 | Compiler Design Lecture 6: Syntax Analysis II 59

Rebuilding the Grammar
 Idea: Force a construction order where
 First decide how many “blocks” there will be of terms
joined by + and – (lower precedence).
 Then, expand those blocks by filling in the integers
multiplied and divided together (higher precedence).
 One possible grammar:
S→T|T+S|T-S
T → int | int * T | int / T

Sahar Selim CSCI415 | Compiler Design Lecture 6: Syntax Analysis II 60

An Unambiguous Grammar

Sahar Selim CSCI415 | Compiler Design Lecture 6: Syntax Analysis II 61

Precedence and
Associativity

Sahar Selim CSCI415 | Compiler Design Lecture 6: Syntax Analysis II 62

Group of Equal Precedence
 The precedence can be added to our simple
expression grammar as follows:
exp  exp addop exp | term
addop  + | -
term  term mulop term | factor
mulop  *
factor  ( exp ) | number
 Addition and subtraction will appear "higher" (that
is, closer to the root) in the parse and syntax trees
 Receive lower precedence

Sahar Selim CSCI415 | Compiler Design Lecture 6: Syntax Analysis II 63

Precedence Cascade
 Grouping operators into different precedence levels
 Cascade is a standard method in syntactic specification
using BNF
 Replacingthe rule
exp  exp addop exp | term
by exp  exp addop term |term (Left Recursive/Associative)
or exp  term addop exp |term (Right Recursive/Associative)

 A left recursive rule makes operators associate on the left

 A right recursive rule makes them associate on the right
Sahar Selim CSCI415 | Compiler Design Lecture 6: Syntax Analysis II 64
Removal of Ambiguity
 Removal of ambiguity in the BNF rules for simple
arithmetic expressions
 write the rules to make all the operations left associative

exp  exp addop term |term

addop + | -
term  term mulop factor | factor
mulop  *
factor  ( exp ) | number

Sahar Selim CSCI415 | Compiler Design Lecture 6: Syntax Analysis II 65

 New Parse Tree
 The parse tree for the expression 34-3*42 is
exp  exp addop term |term
addop + | -
term  term mulop factor | factor
mulop  *
factor  ( exp ) | number

Sahar Selim CSCI415 | Compiler Design Lecture 6: Syntax Analysis II 66

 New Parse Tree
 The parse tree for the expression 34-3-42

• The precedence cascades cause the parse trees to become much more complex
• The syntax trees, however, are not affected
Sahar Selim CSCI415 | Compiler Design Lecture 6: Syntax Analysis II 67
4 The dangling else
problem

Sahar Selim CSCI415 | Compiler Design Lecture 6: Syntax Analysis II 68

The dangling else problem:
An Ambiguity Grammar
 Consider the grammar from:
statement  if-stmt | other
if-stmt  if ( exp ) statement | if ( exp ) statement else statement
exp  0 | 1
 This grammar is ambiguous as a result of the optional
else.
 Consider the string
if (0) if (1) other else other

Sahar Selim CSCI415 | Compiler Design Lecture 6: Syntax Analysis II 69

if (0) if (1) other else other
statement  if-stmt | other
if-stmt  if ( exp ) statement | if ( exp ) statement else statement
exp  0 | 1

Sahar Selim CSCI415 | Compiler Design Lecture 6: Syntax Analysis II 70

if (0) if (1) other else other
statement  if-stmt | other
if-stmt  if ( exp ) statement | if ( exp ) statement else statement
exp  0 | 1

Sahar Selim CSCI415 | Compiler Design Lecture 6: Syntax Analysis II 71

Dangling else problem
 Which tree is correct depends on associating
the single else-part with the first or the second
if-statement.
 The first associates the else-part with the first if-
statement;
 The second associates it with the second if-statement.

 This ambiguity is called dangling else problem

 This disambiguating rule is the most closely
nested rule
 implies that the second parse tree is the correct one.
Sahar Selim CSCI415 | Compiler Design Lecture 6: Syntax Analysis II 72
Example
if (x != 0)
if (y = = 1/x) ok = TRUE;
else z = 1/x;
 Note that, if we wanted we could associate the
else-part with the first if-statement by using
brackets {...} in C, as in
if (x != 0)
{ if (y = = 1/x) ok = TRUE; }
else z = 1/x;

Sahar Selim CSCI415 | Compiler Design Lecture 6: Syntax Analysis II 73

A Solution to the dangling else
ambiguity in the BNF
statement  matched-stmt | unmatched-stmt
matched-stmt  if ( exp ) matched-stmt else matched-stmt | other
unmatched-stmt  if ( exp ) statement |
if ( exp ) matched-stmt else unmatched-stmt
exp  0 | 1

 Permitting only a matched-stmt to come before an else

in an if-statement
 forcing all else-parts to be matched as soon as possible.

Sahar Selim CSCI415 | Compiler Design Lecture 6: Syntax Analysis II 74

if (0) if (1) other else other
statement  matched-stmt | unmatched-stmt
matched-stmt  if ( exp ) matched-stmt else matched-stmt | other
unmatched-stmt  if ( exp ) statement |
if ( exp ) matched-stmt else unmatched-stmt
exp  0 | 1

Sahar Selim CSCI415 | Compiler Design Lecture 6: Syntax Analysis II 75

76
Review Questions

Sahar Selim CSCI415 | Compiler Design Lecture 6: Syntax Analysis II 77

Problem 1
 Check whether the following grammar G is ambiguous
or not given the production rules:
X → X+X | X*X |X| a

Sahar Selim CSCI415 | Compiler Design Lecture 6: Syntax Analysis II 78

Problem 1 Solution
 find out the derivation tree for the string
"a+a*a". It has two leftmost derivations.
Derivation 1 −  Derivation 2 − 
X → X+X → a +X → a+ X*X → X → X*X → X+X*X → a+ X*X → a+a*X
a+a*X → a+a*a → a+a*a

Then this grammar is ambiguous

Sahar Selim CSCI415 | Compiler Design Lecture 6: Syntax Analysis II 79
Problem 2
Show that the grammar G with the following
production is ambiguous.
S → a | aAb | abSb
A → aAAb | bS

Sahar Selim CSCI415 | Compiler Design Lecture 6: Syntax Analysis II 80

Problem 2 Solution
S ⟹ abSb ( ∵ S → abSb)
⟹ abab (∵ S → a)
 Similarly,

S ⟹ aAb ( ∵ S → aAb)
⟹ abSb (∵ A → bS)
⟹ abab (∵ S → a)

 Since‘abab’ has two different derivations, the

grammar G is ambiguous.
Sahar Selim CSCI415 | Compiler Design Lecture 6: Syntax Analysis II 81
Problem 3
 Convert the following ambiguous grammar
into unambiguous grammar.
R → R + R | R . R | R* | a | b
 where * is kleen closure and . is concatenation.

Sahar Selim CSCI415 | Compiler Design Lecture 6: Syntax Analysis II 82

Problem 3 Solution
 To convert the given grammar into its corresponding
unambiguous grammar, we implement the
precedence and associativity constraints.
 We have
 Given grammar consists of the following operators + , . , *
 Given grammar consists of the following operands a , b
 The priority order is (a , b) > * > . > + where
 . operator is left associative
+ operator is left associative

Sahar Selim CSCI415 | Compiler Design Lecture 6: Syntax Analysis II 83

Problem 3 Solution
 Using the precedence and associativity rules, we
write the corresponding unambiguous grammar as

E → E + T | T E → E + T | T
T → T . F | F OR T → T . F | F
F → F * F | G F → F * F | a | b
G → a | b

Sahar Selim CSCI415 | Compiler Design Lecture 6: Syntax Analysis II 84

Problem 4
 Write the CFG and Parse tree that can generates
the following expression
float x,y,z

Sahar Selim CSCI415 | Compiler Design Lecture 6: Syntax Analysis II 85

Summary
 Syntax analysis (parsing) extracts the structure
from the tokens produced by the scanner.
 Languages are usually specified by context-free
grammars (CFGs).
A parse tree shows how a string can be derived
from a grammar.
 Abstract syntax trees (ASTs) contain an abstract
representation of a program's syntax.

Sahar Selim CSCI415 | Compiler Design Lecture 6: Syntax Analysis II 86

Summary
A grammar is ambiguous if it can derive the same string
multiple ways.
A CFG is said to be ambiguous if there is at least one string
with two or more parse trees.
 Note that ambiguity is a property of grammars, not languages.
 There is no algorithm for eliminating ambiguity; it must be
done by hand.
 Some Grammars are inherently ambiguous, meaning that no
unambiguous grammar exists for them .
 There is no algorithm for detecting whether an arbitrary
grammar is ambiguous.

Sahar Selim CSCI415 | Compiler Design Lecture 6: Syntax Analysis II 87

Summary
 If a grammar can be made unambiguous at all,
it is usually made unambiguous through
layering.
 Have exactly one way to build each piece of
the string.
 Have exactly one way of combining those
pieces back together.

Sahar Selim CSCI415 | Compiler Design Lecture 6: Syntax Analysis II 88

References of this lecture
 Presentation slides of the book: COMPILER
CONSTRUCTION, Principles and Practice, by
Kenneth C. Louden
 Credits for Dr. Sally Saad, Prof. Mostafa Aref, Dr.
Islam Hegazy, and Dr. Abd ElAziz for help in
content preparation and aggregation (FCIS-ASU)

Sahar Selim CSCI415 | Compiler Design Lecture 6: Syntax Analysis II 89

Supplementary References

A good video explaining ambiguity and

disambiguating the CFG

https://youtu.be/9vmhcBpZDcE

Sahar Selim CSCI415 | Compiler Design Lecture 6: Syntax Analysis II 90

 See you
next
lecture
Sahar Selim CSCI415 | Compiler Design Lecture 6: Syntax Analysis II 91