Karadeniz Teknik Üniversitesi

Where Syntax Meets Semantics

Karadeniz Teknik Üniversitesi Chapter Three Programming Languages 1

 Three “Equivalent” Grammars
G1: <subexp> ::= a | b | c | <subexp> - <subexp>

G2: <subexp> ::= <var> - <subexp> | <var>

<var> ::= a | b | c

G3: <subexp> ::= <subexp> - <var> | <var>

<var> ::= a | b | c
These grammars all define the same language: the language
of strings that contain one or more a’s, b’s or c’s separated
by minus signs.

But the parse trees are not equivalent.

Karadeniz Teknik Üniversitesi Chapter Three Programming Languages 2
Parse of: a-(b-c)
a-b-c <subexp>

<var> - <subexp>

G2 parse tree: a <var> - <subexp>

b <var>
G2: <subexp> ::= <var> - <subexp> | <var>
<var> ::= a | b | c c

G3: <subexp> ::= <subexp> - <var> | <var> <subexp>

<var> ::= a | b | c
<subexp> - <var>

G3 parse tree: <subexp> - <var> c

<var> b
(a-b)-c
a
Karadeniz Teknik Üniversitesi Chapter Three Programming Languages 3
 Why Parse Trees Matter
• We want the structure of the parse tree to
correspond to the semantics of the string it
generates
• This makes grammar design much harder:
we’re interested in the structure of each parse
tree, not just in the generated string
• Parse trees are where syntax meets semantics

Karadeniz Teknik Üniversitesi Chapter Three Programming Languages 4

 Outline
• Operators
• Precedence
• Associativity
• Other ambiguities: dangling else
• Cluttered grammars
• Parse trees and EBNF
• Abstract syntax trees
• Reverse Polish Notation and Evaluation
Karadeniz Teknik Üniversitesi Chapter Three Programming Languages 5
 Operators
• Special syntax for frequently-used simple
operations like addition, subtraction,
multiplication and division
• The word operator refers both to the token
used to specify the operation (like + and *)
and to the operation itself
• Usually predefined, but not always
• Usually a single token, but not always

Karadeniz Teknik Üniversitesi Chapter Three Programming Languages 6

 Operator Terminology
• Operands are the inputs to an operator, like
1 and 2 in the expression 1+2
• Unary operators take one operand: -1
• Binary operators take two: 1+2
• Ternary operators take three: a?b:c

Karadeniz Teknik Üniversitesi Chapter Three Programming Languages 7

 More Operator Terminology
• In most programming languages, binary operators
use an infix notation: a + b
• Sometimes you see prefix notation: + a b
 What is (* (+ 3 4) 2)?
 What is * + 3 4 2 ?
• Sometimes postfix notation: a b +
 What is (2 (3 4 +) *)?
 What is 2 3 4 + * ?
• Unary operators, similarly:
 (Can’t be infix, of course)
 Can be prefix, as in -1
 Can be postfix, as in a++

Karadeniz Teknik Üniversitesi Chapter Three Programming Languages 8

 Outline
• Operators
• Precedence
• Associativity
• Other ambiguities: dangling else
• Cluttered grammars
• Parse trees and EBNF
• Abstract syntax trees
• Reverse Polish Notation and Evaluation
Karadeniz Teknik Üniversitesi Chapter Three Programming Languages 9
 Working Grammar – G4
G4: <exp> ::= <exp> + <exp> |
<exp> * <exp> |
(<exp>) |
a | b | c

This generates a language of arithmetic expressions

using parentheses, the operators + and *, and the
variables a, b and c

Karadeniz Teknik Üniversitesi Chapter Three Programming Languages 10

 Issue #1: Precedence
G4: <exp> ::= <exp> + <exp> |
<exp> * <exp> |
(<exp>) |
a | b | c
Our G4 grammar can generate two trees for a+b*c. In the left tree,
the addition is performed before the multiplication, which is not the
usual convention for operator precedence.
a+(b*c)
(a+b)*c <exp> <exp>

<exp> * <exp> <exp> + <exp>

<exp> + <exp> c a <exp> * <exp>

a b b c
Karadeniz Teknik Üniversitesi Chapter Three Programming Languages 11
 Operator Precedence
• Applies when the order of evaluation is not
completely decided by parentheses
• Each operator has a precedence level, and those
with higher precedence are performed before those
with lower precedence, as if parenthesized
• Most languages put * at a higher precedence level
than +, so that:

a+b*c = a+(b*c)

Karadeniz Teknik Üniversitesi Chapter Three Programming Languages 12

 Precedence Examples
• C (15 levels of precedence—too many?)
a = b < c ? * p + b * c : 1 << d ()

• Pascal (5 levels—not enough?)

a <= 0 or 100 <= a Error!

• Smalltalk (1 level for all binary operators)

a + b * c
Karadeniz Teknik Üniversitesi Chapter Three Programming Languages 13
 Precedence In The Grammar
G4: <exp> ::= <exp> + <exp>
| <exp> * <exp>
| (<exp>)
| a | b | c
G5: <exp> ::= <exp> + <exp> | <mulexp>
<mulexp> ::= <mulexp> * <mulexp>
| (<exp>)
| a | b | c

• Fix precedence: Modify grammar to put * below + in

the parse tree in G5.
• <exp> defined in terms of <mulexp> therefore higher in
parse tree and lower precedence.
Karadeniz Teknik Üniversitesi Chapter Three Programming Languages 14
Correct Precedence
G5: <exp> ::= <exp> + <exp> | <mulexp>
<mulexp> ::= <mulexp> * <mulexp>
| (<exp>)
| a | b | c
Our new grammar generates this tree for a+b*c. It generates
the same language as before, but no longer generates parse
trees with incorrect precedence. <exp>

a+b*c <exp> + <exp>

G5 parse tree: <mulexp> <mulexp>

a <mulexp> * <mulexp>

b c
Karadeniz Teknik Üniversitesi Chapter Three Programming Languages 15
Parse G5: <exp> ::= <exp> + <exp> | <mulexp>
<mulexp> ::= <mulexp> * <mulexp>
| (<exp>)
| a | b | c

a + b * c
<exp>
<exp> = <exp> + <exp>
= <exp> + <mulexp>
= <mulexp> + <mulexp>
<exp> + <exp>
= a + <mulexp> <mulexp> <mulexp>
= a + <mulexp> * <mulexp>
=a+ b * c a <mulexp> * <mulexp>

b c

Karadeniz Teknik Üniversitesi Chapter Three Programming Languages 16

 Exercise 1
<exp> ::= <exp> - <exp> | <mulexp>
<mulexp> ::= <mulexp> * <mulexp> | 1 | 2 | 3

For the language defined by the grammar above, give

the parse tree and select the value of each:
1. 1-2*3? -5 3 –3 7
2. 1-2-3? -4 2 –2 0
3. 1-3-2? -4 2 –2 0
Which are valid for the above grammar?
1. 1-1-1
2. 2*3
3. 2*2*3
4. 2*3-1

Karadeniz Teknik Üniversitesi Chapter Three Programming Languages 17

 Outline
• Operators
• Precedence
• Associativity
• Other ambiguities: dangling else
• Cluttered grammars
• Parse trees and EBNF
• Abstract syntax trees
• Reverse Polish Notation and Evaluation
Karadeniz Teknik Üniversitesi Chapter Three Programming Languages 18
 Issue #2: Associativity
(a+b)+c
a+(b+c)
<exp> <exp>

<exp> + <exp> <exp> + <exp>

<mulexp> <exp> + <exp> <exp> + <exp> <mulexp>

a <mulexp> <mulexp> <mulexp> <mulexp> c

b c a b

Our grammar G5 generates both these trees for a+b+c. The first
one is not the usual convention for operator associativity.
G5: <exp> ::= <exp> + <exp> | <mulexp>
<mulexp> ::= <mulexp> * <mulexp>
| (<exp>)
| a | b | c
Karadeniz Teknik Üniversitesi Chapter Three Programming Languages 19
 Operator Associativity
• Applies when the order of evaluation is not
decided by parentheses or by precedence
• Left-associative operators group left to
right: a+b+c+d = ((a+b)+c)+d
• Right-associative operators group right to
left: a+b+c+d = a+(b+(c+d))
• Most operators in most languages are left-
associative, but there are exceptions

Karadeniz Teknik Üniversitesi Chapter Three Programming Languages 20

 Associativity Examples
• C
a<<b<<c — most operators are left-associative
a=b=0 — right-associative (assignment)

• ML
3-2-1 — most operators are left-associative
1::2::nil — right-associative (list builder)

• Fortran
a/b*c — most operators are left-associative
a**b**c — right-associative (exponentiation)

Karadeniz Teknik Üniversitesi Chapter Three Programming Languages 21

 Associativity In The Grammar
G5: <exp> ::= <exp> + <exp> | <mulexp>
<mulexp> ::= <mulexp> * <mulexp>
| (<exp>)
| a | b | c
G6: <exp> ::= <exp> + <mulexp> | <mulexp>
<mulexp> ::= <mulexp> * <rootexp> | <rootexp>
<rootexp> ::= (<exp>) | a | b | c

• Fix associativity: Modify the grammar to make trees of

+s grow down to the left (and likewise for *s) in G6.
• G5 ambiguous: <exp>+<exp> is right and left recursive.
• G6: Left recursive rule alone defines left associativity,
<exp> + <mulexp> and <mulexp> * <rootexp>
Karadeniz Teknik Üniversitesi Chapter Three Programming Languages 22
Correct Associativity <exp> (a+b)+c

Our new grammar <exp> + <mulexp>

generates this tree for
a+b+c. It generates <rootexp>
<exp> + <mulexp>
the same language as
<mulexp> <rootexp> c
before, but no longer
generates trees with
<rootexp> b
incorrect associativity.
a

G6: <exp> ::= <exp> + <mulexp> | <mulexp>

<mulexp> ::= <mulexp> * <rootexp> | <rootexp>
<rootexp> ::= (<exp>) | a | b | c

Karadeniz Teknik Üniversitesi Chapter Three Programming Languages 23

 Exercise 2
<exp> ::= <exp> - <mulexp> | <mulexp>
<mulexp> ::= <mulexp> * <rootexp> | <rootexp>
<rootexp> ::= 1 | 2 | 3

For the language defined by the grammar,

give the parse tree and the value of the
following:
a) 1-2*3? -5 3 –3 7
b) 1-2-3? -4 2 –2 0
c) 1-3-2? -4 2 –2 0

Karadeniz Teknik Üniversitesi Chapter Three Programming Languages 24

 Exercise 2 Continued
Starting with this grammar:
G6: <exp> ::= <exp> + <mulexp> | <mulexp>
<mulexp> ::= <mulexp> * <rootexp> | <rootexp>
<rootexp> ::= (<exp>)
| a | b | c
d) Add subtraction and division (- and /) with the customary
precedence and associativity.
e) Add a left-associative operator % between the + and * in
precedence.
f) Add a right-associative = operator, at lower precedence than any
of the others
g) Add parenthesis to reflect the parse under definition f?
a) a = b + c
b) a + b = b * c
Karadeniz Teknik Üniversitesi Chapter Three Programming Languages 25
 Outline
• Operators
• Precedence
• Associativity
• Other ambiguities: dangling else
• Cluttered grammars
• Parse trees and EBNF
• Abstract syntax trees
• Reverse Polish Notation and Evaluation
Karadeniz Teknik Üniversitesi Chapter Three Programming Languages 26
 Issue #3: Ambiguity
• G4 was ambiguous: it generated more than
one parse tree for the same string
• Fixing the precedence (in G5) and
associativity (in G6) problems eliminated
all the ambiguity
• This is usually a good thing: the parse tree
corresponds to the meaning of the program,
and we don’t want ambiguity about that
• Not all ambiguity stems from confusion
about precedence and associativity...
Karadeniz Teknik Üniversitesi Chapter Three Programming Languages 27
 Dangling Else In Grammars
<stmt> ::= <if-stmt> | s1 | s2
<if-stmt> ::= if <expr> then <stmt> else <stmt>
| if <expr> then <stmt>
<expr> ::= e1 | e2

This grammar has a classic “dangling-else ambiguity.” The

statement we want to derive is

if e1 then if e2 then s1 else s2

and the next slide shows two different parse trees for it...

Karadeniz Teknik Üniversitesi Chapter Three Programming Languages 28

if e1 then (if e2 then s1) else s2
<if-stmt>

if <exp> then <stmt> else <stmt>

e1 <if-stmt> s2 Ambiguous
if <exp> then <stmt>
if-then-else
e2 s1 parse trees
if e1 then (if e2 then s1 else s2)
<if-stmt>

if <exp> then <stmt>

Most languages that have
e1 <if-stmt> this problem choose this
parse tree: else goes with
nearest unmatched then
if <exp> then <stmt> else <stmt>

e2 s1 s2
 Eliminating The Ambiguity
<stmt> ::= <if-stmt> | s1 | s2
<if-stmt> ::= if <expr> then <stmt> else <stmt>
| if <expr> then <stmt>
<expr> ::= e1 | e2

•We want to insist that if this expands into an if, that if must
already have its own else.
•First, we make a new non-terminal <full-stmt> that generates
everything <stmt> generates.
•Except that it can not generate if statements with no else:

Karadeniz Teknik Üniversitesi Chapter Three Programming Languages 30

 Eliminating The Ambiguity

if e1 then if e2 then s1 else s2

G7:
<full-stmt> ::= <full-if> | s1 | s2
<full-if> ::= if <expr> then <full-stmt> else <full-stmt>

<stmt> ::= <if-stmt> | s1 | s2

<if-stmt> ::= if <expr> then <full-stmt> else <stmt> |
if <expr> then <stmt>
<expr> ::= e1 | e2

•Use the new <full-stmt> non-terminal here.

•The effect is the new grammar can match an else part
with an if part only if all the nearer if parts are already
matched.

Karadeniz Teknik Üniversitesi Chapter Three Programming Languages 31

G7: Parse

<full-stmt> ::= <full-if> | s1 | s2

<full-if> ::= if <expr> then <full-stmt> else <full-stmt>
<stmt> ::= <if-stmt> | s1 | s2
<if-stmt> ::= if <expr> then <full-stmt> else <stmt> |
if <expr> then <stmt>
<expr> ::= e1 | e2

if e1 then if e2 then s1 else s2

<stmt> = <if-stmt>
= if <expr> then <stmt>
= if <expr> then <if-stmt>
= if <expr> then if <expr> then <full-stmt> else <stmt>
= if e1 then if <expr> then <full-stmt> else <stmt>
= if e1 then if e2 then <full-stmt> else <stmt>
= if e1 then if e2 then s1 else <stmt>
= if e1 then if e2 then s1 else s2

Karadeniz Teknik Üniversitesi Chapter Three Programming Languages 32

<full-stmt> ::= <full-if> |
Parse
s1 | s2
<full-if> ::= if <expr> then <full-stmt> else <full-stmt>
<stmt> ::= <if-stmt> | s1 | s2
<if-stmt> ::= if <expr> then <full-stmt> else <stmt> |
if <expr> then <stmt>
<expr> ::= e1 | e2

if e1 then if e2 then s1 else s2

Correct
<if-stmt> Parse
if <exp> then <stmt> Tree
e1 <if-stmt>

if <exp> then <full-stmt> else <stmt>

e2 s1 s2
Karadeniz Teknik Üniversitesi Chapter Three Programming Languages 33
<full-stmt> ::= if <expr> then <full-stmt> else <full-stmt> |
Parse
Correct
Parse
Tree

s1 | s2 | s3
<stmt> ::= <if-stmt> | s1 | s2 | s3
<if-stmt> ::= if <expr> then <full-stmt> else <stmt> |
if <expr> then <stmt>
<expr> ::= e1 | e2
if e1 then if e2 then s1 else s2 else s3

<if-stmt>

if <exp> then <full-stmt> else <stmt>

e1 if <exp> then <full-stmt> else <full-stmt> s3

e2 s1 s2

Karadeniz Teknik Üniversitesi Chapter Three Programming Languages 34

 Dangling Else
• We fixed the grammar, but…
• The grammar trouble reflects a problem
with the language, which we did not change
• A chain of if-then-else constructs can be
very hard for people to read
• Especially true if some but not all of the
else parts are present

Karadeniz Teknik Üniversitesi Chapter Three Programming Languages 35

Exercise 3 Give the parse tree for each <stmt>.

<full> ::= if <expr> then <full> else <full> |

Parse

s1 | s2 | s3
<stmt> ::= if <expr> then <full> else <stmt> |
if <expr> then <stmt> |
s1 | s2 | s3
<expr> ::= e1 | e2

1. if e1 then s1
2. if e1 then if e2 then s1
3. if e1 then if e2 then s1 else s2
4. if e1 then if e2 then s1 else s2 else s3
5. if e1 then s1 else if e2 then s1 else s2

Karadeniz Teknik Üniversitesi Chapter Three Programming Languages 36

 Clearer Styles

int a=0;
if (0==0) Better: correct indentation
if (0==1) a=1;
else a=2;

int a=0;
if (0==0) {
Even better: use of a block
if (0==1) a=1;
reinforces the structure
else a=2;
}

Karadeniz Teknik Üniversitesi Chapter Three Programming Languages 37

 Languages That Don’t Dangle
• Some languages define if-then-else in a way
that forces the programmer to be more clear
• Algol does not allow the then part to be
another if statement – though it can be a
block containing an if statement
• Ada requires each if statement to be
terminated with an end if

Karadeniz Teknik Üniversitesi Chapter Three Programming Languages 38

 Outline
• Operators
• Precedence
• Associativity
• Other ambiguities: dangling else
• Cluttered grammars
• Parse trees and EBNF
• Abstract syntax trees
• Reverse Polish Notation and Evaluation
Karadeniz Teknik Üniversitesi Chapter Three Programming Languages 39
 Clutter
• The new if-then-else grammar is harder for
people to read than the old one
• It has a lot of clutter: more productions and
more non-terminals
• Same with G4, G5 and G6: we eliminated
the ambiguity but made the grammar harder
for people to read
• This is not always the right trade-off

Karadeniz Teknik Üniversitesi Chapter Three Programming Languages 40

 Reminder: Multiple Audiences
• In Chapter 2 we saw that grammars have
multiple audiences:
 Novices want to find out what legal programs
look like
 Experts—advanced users and language system
implementers—want an exact, detailed definition
 Tools—parser and scanner generators—want an
exact, detailed definition in a particular,
machine-readable form
• Tools often need ambiguity eliminated, while
people often prefer a more readable grammar
Karadeniz Teknik Üniversitesi Chapter Three Programming Languages 41
 Options
• Rewrite grammar to eliminate ambiguity
• Leave ambiguity but explain in
accompanying text how things like
associativity, precedence, and the dangling
else should be parsed
• Do both in separate grammars

Karadeniz Teknik Üniversitesi Chapter Three Programming Languages 42

 Outline
• Operators
• Precedence
• Associativity
• Other ambiguities: dangling else
• Cluttered grammars
• Parse trees and EBNF
• Abstract syntax trees
• Reverse Polish Notation and Evaluation
Karadeniz Teknik Üniversitesi Chapter Three Programming Languages 43
 EBNF and Parse Trees
• You know that {x} or x* means "zero or
more repetitions of x" in EBNF
• So <exp> ::= <mulexp> {+ <mulexp>}
should mean a <mulexp> followed by zero
or more repetitions of "+ <mulexp>"
• But what then is the associativity of that +
operator? What kind of parse tree would be
generated for a+a+a?

Karadeniz Teknik Üniversitesi Chapter Three Programming Languages 44

 Two Camps
• Some people use EBNF loosely:
 Use {} anywhere it helps
 Add a paragraph of text dealing with
ambiguities, associativity of operators, etc.
• Other people use EBNF strictly:
 Use <exp> ::= <mulexp> {+ <mulexp>} only
for left-associative operators
 Use recursive rules for right-associative
operators: <expa> ::= <expb> [ = <expa> ]

Karadeniz Teknik Üniversitesi Chapter Three Programming Languages 45

 About Syntax Diagrams
• Similar problem: what parse tree is
generated?
• As in loose EBNF applications, add a
paragraph of text dealing with ambiguities,
associativity, precedence, and so on

Karadeniz Teknik Üniversitesi Chapter Three Programming Languages 46

 Outline
• Operators
• Precedence
• Associativity
• Other ambiguities: dangling else
• Cluttered grammars
• Parse trees and EBNF
• Abstract syntax trees
• Reverse Polish Notation and Evaluation
Karadeniz Teknik Üniversitesi Chapter Three Programming Languages 47
 Full-Size Grammars
• In any realistically large language, there are
many non-terminals
• Especially true when in the cluttered but
unambiguous form needed by parsing tools
• Extra non-terminals guide construction of
unique parse tree
• Once parse tree is found, such non-
terminals are no longer of interest

Karadeniz Teknik Üniversitesi Chapter Three Programming Languages 48

 Abstract Syntax Tree
• Language systems usually store an
abbreviated version of the parse tree called
the Abstract Syntax Tree
• Details are implementation-dependent
• Usually, there is a node for every operation,
with a subtree for every operand

Karadeniz Teknik Üniversitesi Chapter Three Programming Languages 49

 parse tree
<exp>

<exp> + <mulexp>

<exp> + <mulexp> <rootexp> Example

<mulexp> <rootexp> c
+
<rootexp> b

a
+ c
Abstract Syntax Tree
a b

Karadeniz Teknik Üniversitesi Chapter Three Programming Languages 50

 Outline
• Operators
• Precedence
• Associativity
• Other ambiguities: dangling else
• Cluttered grammars
• Parse trees and EBNF
• Abstract syntax trees
• Reverse Polish Notation and Evaluation
Karadeniz Teknik Üniversitesi Chapter Three Programming Languages 51
 AST to Reverse Polish Notation
and Evaluation
• Abstract Syntax Tree holds the infix
expression operations and operands.
• Traversing the AST in post-order produces
the RPN.
• RPN operator precedence is unambiguous.
• Operands are arranged in proper order for
post-order evaluation.
• Easily evaluated on hardware using a stack.
Karadeniz Teknik Üniversitesi Chapter Three Programming Languages 52
 Parse Tree: 1-2*3+4
<exp> ::= <exp>-<mulexp> | <exp> + <mulexp> | <mulexp>
<mulexp> ::= <mulexp> * <rootexp> | <rootexp>
<rootexp> ::= 1 | 2 | 3 | 4
<exp>
1-2*3+4
<exp> + <mulexp>

<exp> - <mulexp> <rootexp>

<mulexp> <mulexp> * <rootexp> 4

<rootexp> <rootexp> 3

1 2
Karadeniz Teknik Üniversitesi Chapter Three Programming Languages 53
 Abstract Syntax Tree: 1-2*3+4
<exp>
parse tree
<exp> + <mulexp>

<exp> - <mulexp> <rootexp>

<mulexp> <mulexp> * <rootexp> 4

<rootexp> <rootexp> 3
+
1 2
- 4

Abstract Syntax Tree 1 *

2 3
Karadeniz Teknik Üniversitesi Chapter Three Programming Languages 54
 Post-order traversal and RPN

abstract syntax tree Postorder traversal RPN

+
void postOrder(tree t) {
- 4 if (t != null)
postOrder( t.left ); 123*-4+
1 * postOrder( t.right );
cout << t.data;
2 3 }

Karadeniz Teknik Üniversitesi Chapter Three Programming Languages 55

 RPN Evaluation using a Stack
1. Scan RPN input from left to right.
Input Stack Push
1 | 2 | 3 | 4 input
push input onto stack. 123*-4+ 1 1
+ | - | * input 23*-4+ 12 2
1. pop operand2
pop operand1 3*-4+ 123 3
2. push operand1 * operand2
or *-4+ 16 2*3
push operand1 – operand2
or -4+ -5 1-6
push operand1 + operand2
4+ -5 4 4
2. After RPN is scanned, the expression
value is stack top. + -1 -5 + 4

Java Expression Parser and Evaluator

Try the Java applet, which is given to enter expressions in the
form specified in the expression grammar, parse, generate RPN,
and evaluate the RPN. Source code for the applet is available.
Karadeniz Teknik Üniversitesi Chapter Three Programming Languages 56
Exercise 4
<exp>
parse tree
<exp> * <mulexp>

<rootexp> <exp> - <mulexp>

4 <mulexp> <mulexp> + <rootexp>

<rootexp> <rootexp> 3

1 2

1. Give the AST of the parse tree.

2. The corresponding RPN.
3. The value from the RPN evaluation.
Karadeniz Teknik Üniversitesi Chapter Three Programming Languages 57
 Exercise 5
<addop> ::= + | -
<mulop> ::= * | /
<digit> ::= 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9
<factor> ::= <digit> | ( expression )
<term> ::= <term> <mulop> <factor> | <factor>
<expression> ::= <expression> <addop> <term> | <term>

• Given the above BNF rules, generate the AST for

expressions:
 6+5-8
 2+9/3-1
• Traverse the AST nodes in post order to produce the Reverse
Polish Notation.
• Evaluate and compare with the results of the parser applet.
Karadeniz Teknik Üniversitesi Chapter Three Programming Languages 58
 Parsing, Revisited
• When a language system parses a program,
it goes through all the steps necessary to
find the parse tree
• But it usually does not construct an explicit
representation of the parse tree in memory
• Most systems construct an AST instead
• We will see ASTs again in Chapter 23

Karadeniz Teknik Üniversitesi Chapter Three Programming Languages 59

 Parser Generators
• There are many tools that automate
scanning and parsing stages of
programming languages
• In Java: javaCC, sableCC
• Basic Unix tool
 YACC : converts a context-free grammar into a
runnable parser (*.y  y.tab.c)

Karadeniz Teknik Üniversitesi Chapter Three Programming Languages 60

 YACC and Semantic Actions
• YACC can generate a parser based on a
grammar which specifies
 a set of production rules
 semantic actions
• Format for a pair of rule and semantic action:
name : non-teminals and tokens { action; }
| alternatives { action; }
;

Karadeniz Teknik Üniversitesi Chapter Three Programming Languages 61

 Grammar rules for YACC
Definitions:
%start line means the whole input should match line
%union lists all possible types for values associated
with parts of the grammar and gives each a
field-name
%type gives an individual type for the values
associated with each part of the grammar,
using the field-names from the %union
declaration

Karadeniz Teknik Üniversitesi Chapter Three Programming Languages 62

 Grammar rules for YACC
Actions, C declarations and code:
$$ resulting value for any part of the grammar
$1, $2, etc. values from sub-parts of the grammar
yyparse routine created by YACC from (expected
input, action) lists. (It actually returns a value
indicating if it failed to recognise the input.)
yylex routine called by yyparse for all its input. We
are using getchar, which just reads characters
from the input.
yyerror routine called by yyparse whenever it detects
an error in its input.

Karadeniz Teknik Üniversitesi Chapter Three Programming Languages 63

 YACC program for an infix calculator

/*** File: calc.y ***/

%{ /* C declarations used in actions */

#include <stdio.h>
%}

/* yacc definitions */

%union {int a_number;}

%start line
%type <a_number> exp term factor number digit

Karadeniz Teknik Üniversitesi Chapter Three Programming Languages 64

 YACC program for an infix calculator

%%
/* production rules semantic actions (in C)*/
line : exp ';' '\n' { printf ("result is %d\n", $1); }
;
exp : term { $$ = $1; }
| exp '+' term { $$ = $1 + $3; }
| exp '-' term { $$ = $1 - $3; }
;
term : factor { $$ = $1; }
| term '*' factor { $$ = $1 * $3; }
| term '/' factor { $$ = $1 / $3; }
;
factor : number { $$ = $1; }
| '(' exp ')' { $$ = $2; }
;

Karadeniz Teknik Üniversitesi Chapter Three Programming Languages 65

 YACC program for an infix calculator

number : digit { $$ = $1; }

| number digit { $$ = $1*10 + $2; }
;
digit : '0' { $$ = 0; }
| '1' { $$ = 1; }
| '2' { $$ = 2; }
| '3' { $$ = 3; }
| '4' { $$ = 4; }
| '5' { $$ = 5; }
| '6' { $$ = 6; }
| '7' { $$ = 7; }
| '8' { $$ = 8; }
| '9' { $$ = 9; }
;

Karadeniz Teknik Üniversitesi Chapter Three Programming Languages 66

 YACC program for an infix calculator

%% /* C code */

int main (void) {return yyparse ( );}

int yylex (void) {return getchar ( );}

void yyerror (char *s) {fprintf (stderr, "%s\n", s);}

Karadeniz Teknik Üniversitesi Chapter Three Programming Languages 67

 How YACC is used?
$> yacc calc.y  y.tab.c (rename it as calc.c)
$> gcc -o calc calc.c  calc
$> calc
2+3*5–7;
result is 10

Karadeniz Teknik Üniversitesi Chapter Three Programming Languages 68

 Using FLEX and YACC together
• YACC cannot represent numbers as [0-9]+ nor
easily obtain the corresponding value, nor can it
easily be used to ignore white space and
comments.
• We need to use both FLEX and YACC together;
FLEX for the simple parts (e.g. numbers, white
space, comments) and YACC for more complex
parts (e.g. expressions).

Karadeniz Teknik Üniversitesi Chapter Three Programming Languages 69

 YACC code for infix calculator
/*** File: calcy.y ***/
%{
#include <stdio.h>
%}

%union {int a_number;}

%start line
%token <a_number> number
%type <a_number> exp term factor

%%
line : exp ';' {printf ("result is %d\n", $1);}
;

Karadeniz Teknik Üniversitesi Chapter Three Programming Languages 70

 YACC code for infix calculator
exp : term { $$ = $1; }
| exp '+' term { $$ = $1 + $3; }
| exp '-' term { $$ = $1 - $3; }
;
term : factor { $$ = $1; }
| term '*' factor { $$ = $1 * $3; }
| term '/' factor { $$ = $1 / $3; }
;
factor : number { $$ = $1; }
| '(' exp ')' { $$ = $2; }
;
%%
int main (void) {return yyparse ( );}
void yyerror (char *s) {fprintf (stderr, "%s\n", s);}
Karadeniz Teknik Üniversitesi Chapter Three Programming Languages 71
 FLEX code for infix calculator
/*** File: calcl.l ***/
%{
#include "y.tab.h"
%}

%%

[0-9]+ {yylval.a_number = atoi(yytext); return number;}

[ \t\n] ;
[-+*/();] {return yytext[0];}
. {ECHO; yyerror ("unexpected character");}

%%

int yywrap (void) {return 1;}

Karadeniz Teknik Üniversitesi Chapter Three Programming Languages 72

 Declarations
YACC declarations
%token declare each grammar rule used by YACC that
is recognised by FLEX and give type of value

FLEX declarations and actions

y.tab.h gives FLEX the names and type declarations
etc. from YACC
yylval name used for values set in FLEX e.g.
yylval.a_number = atoi (yytext);
yylval.a_name = findname (yytext);

Karadeniz Teknik Üniversitesi Chapter Three Programming Languages 73

 How FLEX and YACC is used?
$> yacc –d calcy.y  y.tab.c y.tab.h
(rename y.tab.c as calcy.c)
$> gcc –c calcy.c  calcy.o
$> flex calcl.l  lex.yy.c (rename it as calcl.c)
$> gcc –c calcl.c  calcl.o
$> gcc –o calc calcl.o calcy.o  calc
$> calc
2+3*5–7;
result is 10

Karadeniz Teknik Üniversitesi Chapter Three Programming Languages 74

 Conclusion
• Grammars define syntax, and more
• They define not just a set of legal programs,
but a parse tree for each program
• The structure of a parse tree corresponds to
the order in which different parts of the
program are to be executed
• Thus, grammars contribute (a little) to the
definition of semantics

Karadeniz Teknik Üniversitesi Chapter Three Programming Languages 75

Karadeniz Teknik Üniversitesi Chapter Three Programming Languages 76