1. Programming Languages and Compilers (CS 421)
Sasa Misailovic
4110 SC, UIUC
Based in part on slides by Mattox Beckman, as updated by Vikram Adve, Gul Agha, and Elsa L Gunter
11/10/2018

2. String with more then one parse: 0 + 1 + 0 1 * 1 + 1
Example
Ambiguous grammar:
<exp> ::= 0 | 1 | <exp> + <exp>
| <exp> * <exp>
String with more then one parse:
1 * 1 + 1
Source of ambiuity: associativity and precedence
11/10/2018

3. Disambiguating a Grammar
Given ambiguous grammar G, with start symbol S, find a grammar G’ with same start symbol, such that
language of G = language of G’
Not always possible
No algorithm in general
11/10/2018

4. Disambiguating a Grammar
Idea: Each non-terminal represents all strings having some property
Identify these properties (often in terms of things that can’t happen)
Use these properties to inductively guarantee every string in language has a unique parse
11/10/2018

5. Steps to Grammar Disambiguation
Identify the rules and a smallest use that display ambiguity
Decide which parse to keep; why should others be thrown out?
What syntactic restrictions on subexpressions are needed to throw out the bad (while keeping the good)?
Add a new non-terminal and rules to describe this set of restricted subexpressions (called stratifying, or refactoring)
Replace old rules to use new non-terminals
Rinse and repeat
11/10/2018

6. Two Major Sources of Ambiguity
Lack of determination of operator precedence
Lack of determination of operator assoicativity
Not the only sources of ambiguity
10/4/07

7. How to Enforce Associativity
Have at most one recursive call per production
When two or more recursive calls would be natural leave right-most one for right assoicativity, left-most one for left assoiciativity
10/4/07

8. Example <Sum> ::= 0 | 1 | <Sum> + <Sum>
Becomes
<Sum> ::= <Num> | <Num> + <Sum>
<Num> ::= 0 | 1 | (<Sum>)
10/4/07

9. Operator Precedence
Operators of highest precedence evaluated first (bind more tightly).
Precedence for infix binary operators given in following table
Needs to be reflected in grammar
10/4/07

10. Predence in Grammar
Higher precedence translates to longer derivation chain
Example:
<exp> ::= 0 | 1 | <exp> + <exp>
| <exp> * <exp>
Becomes
<exp> ::= <mult_exp>
| <exp> + <mult_exp>
<mult_exp> ::= <id> | <mult_exp> * <id>
<id> ::= 0 | 1
10/4/07

11. Disambiguating a Grammar
<exp>::= 0|1| b<exp> | <exp>a
| <exp>m<exp>
Want a has higher precedence than b, which in turn has higher precedence than m, and such that m associates to the left.
11/10/2018

12. Disambiguating a Grammar
<exp>::= 0|1| b<exp> | <exp>a
| <exp>m<exp>
Want a has higher precedence than b, which in turn has higher precedence than m, and such that m associates to the left.
<exp> ::= <exp> m <not m> | <not m>
<not m> ::= b <not m> | <not b m>
<not b m> ::= <not b m>a | 0 | 1
11/10/2018

13. Disambiguating a Grammar – Take 2
<exp>::= 0|1| b<exp> | <exp>a
| <exp>m<exp>
Want b has higher precedence than m, which in turn has higher precedence than a, and such that m associates to the right.
11/10/2018

14. Disambiguating a Grammar – Take 2
<exp>::= 0|1| b<exp> | <exp>a
| <exp>m<exp>
Want b has higher precedence than m, which in turn has higher precedence than a, and such that m associates to the right.
<exp> ::=
<no a m> | <no m> m <no a>| <exp> a
<no a> ::= <no a m> | <no a m> m <no a>
<no m> ::= <no a m> | <exp> a
<no a m> ::= b <no a m> | 0 | 1
11/10/2018

15. LR Parsing Read tokens left to right (L)
Create a rightmost derivation (R)
How is this possible?
Start at the bottom (left) and work your way up
Last step has only one non-terminal to be replaced so is right-most
Working backwards, replace mixed strings by non-terminals
Always proceed so that there are no non-terminals to the right of the string to be replaced
11/10/2018

16. LR Parsing Tables
Build a pair of tables, Action and Goto, from the grammar
This is the hardest part, we omit here
Rows labeled by states
For Action, columns labeled by terminals and “end-of-tokens” marker
(more generally strings of terminals of fixed length)
For Goto, columns labeled by non-terminals
11/10/2018

17. Action and Goto Tables
Given a state and the next input, Action table says either
shift and go to state n, or
reduce by production k (explained in a bit)
accept or error
Given a state and a non-terminal, Goto table says
go to state m
11/10/2018

18. LR(i) Parsing Algorithm
Based on push-down automata
Uses states and transitions (as recorded in Action and Goto tables)
Uses a stack containing states, terminals and non-terminals
11/10/2018

19. LR(i) Parsing Algorithm
0. Insure token stream ends in special “end-of-tokens” symbol
Start in state 1 with an empty stack
Push state(1) onto stack
Look at next i tokens from token stream (toks) (don’t remove yet)
If top symbol on stack is state(n), look up action in Action table at (n, toks)
11/10/2018

20. LR(i) Parsing Algorithm
5. If action = shift m,
Remove the top token from token stream and push it onto the stack
Push state(m) onto stack
Go to step 3
11/10/2018

21. LR(i) Parsing Algorithm
6. If action = reduce k where production k is E ::= u
Remove 2 * length(u) symbols from stack (u and all the interleaved states)
If new top symbol on stack is state(m), look up new state p in Goto(m,E)
Push E onto the stack, then push state(p) onto the stack
Go to step 3
11/10/2018

22. LR(i) Parsing Algorithm
7. If action = accept
Stop parsing, return success
8. If action = error,
Stop parsing, return failure
11/10/2018

23. Example: <Sum> = 0 | 1 | (<Sum>) | <Sum> + <Sum>
=  ( ) shift
11/10/2018

24. LR(i) Parsing Algorithm
0. Insure token stream ends in special “end-of-tokens” symbol
Start in state 1 with an empty stack
Push state(1) onto stack
Look at next i tokens from token stream (toks) (don’t remove yet)
If top symbol on stack is state(n), look up action in Action table at (n, toks)
11/10/2018

25. Example: <Sum> = 0 | 1 | (<Sum>) | <Sum> + <Sum>
=  ( ) shift
11/10/2018

26. LR(i) Parsing Algorithm
5. If action = shift m,
Remove the top token from token stream and push it onto the stack
Push state(m) onto stack
Go to step 3
11/10/2018

27. Example: <Sum> = 0 | 1 | (<Sum>) | <Sum> + <Sum>
= ( ) shift
=  ( ) shift
11/10/2018

28. Example: <Sum> = 0 | 1 | (<Sum>) | <Sum> + <Sum>
=> ( 0  + 1 ) reduce
= ( ) shift
=  ( ) shift
11/10/2018

29. LR(i) Parsing Algorithm
6. If action = reduce k where production k is E ::= u
Remove 2 * length(u) symbols from stack (u and all the interleaved states)
If new top symbol on stack is state(m), look up new state p in Goto(m,E)
Push E onto the stack, then push state(p) onto the stack
Go to step 3
11/10/2018

30. Example: <Sum> = 0 | 1 | (<Sum>) | <Sum> + <Sum>
= ( <Sum>  + 1 ) shift
=> ( 0  + 1 ) reduce
= ( ) shift
=  ( ) shift
11/10/2018

31. Example: <Sum> = 0 | 1 | (<Sum>) | <Sum> + <Sum>
= ( <Sum> +  1 ) shift
= ( <Sum>  + 1 ) shift
=> ( 0  + 1 ) reduce
= ( ) shift
=  ( ) shift
11/10/2018

32. Example: <Sum> = 0 | 1 | (<Sum>) | <Sum> + <Sum>
=> ( <Sum> + 1  ) reduce
= ( <Sum> +  1 ) shift
= ( <Sum>  + 1 ) shift
=> ( 0  + 1 ) reduce
= ( ) shift
=  ( ) shift
11/10/2018

33. Example: <Sum> = 0 | 1 | (<Sum>) | <Sum> + <Sum>
=> ( <Sum> + <Sum>  ) reduce
=> ( <Sum> + 1  ) reduce
= ( <Sum> +  1 ) shift
= ( <Sum>  + 1 ) shift
=> ( 0  + 1 ) reduce
= ( ) shift
=  ( ) shift
11/10/2018

34. LR(i) Parsing Algorithm
6. If action = reduce k where production k is E ::= u
Remove 2 * length(u) symbols from stack (u and all the interleaved states)
If new top symbol on stack is state(m), look up new state p in Goto(m,E)
Push E onto the stack, then push state(p) onto the stack
Go to step 3
11/10/2018

35. Example: <Sum> = 0 | 1 | (<Sum>) | <Sum> + <Sum>
= ( <Sum> ) shift
=> ( <Sum> + <Sum>  ) reduce
=> ( <Sum> + 1  ) reduce
= ( <Sum> +  1 ) shift
= ( <Sum>  + 1 ) shift
=> ( 0  + 1 ) reduce
= ( ) shift
=  ( ) shift
11/10/2018

36. Example: <Sum> = 0 | 1 | (<Sum>) | <Sum> + <Sum>
=> ( <Sum> )  reduce
= ( <Sum> ) shift
=> ( <Sum> + <Sum>  ) reduce
=> ( <Sum> + 1  ) reduce
= ( <Sum> +  1 ) shift
= ( <Sum>  + 1 ) shift
=> ( 0  + 1 ) reduce
= ( ) shift
=  ( ) shift
11/10/2018

37. Example: <Sum> = 0 | 1 | (<Sum>) | <Sum> + <Sum>
= <Sum>  shift
=> ( <Sum> )  reduce
= ( <Sum> ) shift
=> ( <Sum> + <Sum>  ) reduce
=> ( <Sum> + 1  ) reduce
= ( <Sum> +  1 ) shift
= ( <Sum>  + 1 ) shift
=> ( 0  + 1 ) reduce
= ( ) shift
=  ( ) shift
11/10/2018

38. Example: <Sum> = 0 | 1 | (<Sum>) | <Sum> + <Sum>
= <Sum> +  shift
= <Sum>  shift
=> ( <Sum> )  reduce
= ( <Sum> ) shift
=> ( <Sum> + <Sum>  ) reduce
=> ( <Sum> + 1  ) reduce
= ( <Sum> +  1 ) shift
= ( <Sum>  + 1 ) shift
=> ( 0  + 1 ) reduce
= ( ) shift
=  ( ) shift
11/10/2018

39. Example: <Sum> = 0 | 1 | (<Sum>) | <Sum> + <Sum>
=> <Sum> + 0  reduce
= <Sum> +  shift
= <Sum>  shift
=> ( <Sum> )  reduce
= ( <Sum> ) shift
=> ( <Sum> + <Sum>  ) reduce
=> ( <Sum> + 1  ) reduce
= ( <Sum> +  1 ) shift
= ( <Sum>  + 1 ) shift
=> ( 0  + 1 ) reduce
= ( ) shift
=  ( ) shift
11/10/2018

40. Example: <Sum> = 0 | 1 | (<Sum>) | <Sum> + <Sum>
<Sum>  => <Sum> + <Sum >  reduce
=> <Sum> + 0  reduce
= <Sum> +  shift
= <Sum>  shift
=> ( <Sum> )  reduce
= ( <Sum> ) shift
=> ( <Sum> + <Sum>  ) reduce
=> ( <Sum> + 1  ) reduce
= ( <Sum> +  1 ) shift
= ( <Sum>  + 1 ) shift
=> ( 0  + 1 ) reduce
= ( ) shift
=  ( ) shift
11/10/2018

41. Example: <Sum> = 0 | 1 | (<Sum>) | <Sum> + <Sum>
<Sum>  => <Sum> + <Sum >  reduce
=> <Sum> + 0  reduce
= <Sum> +  shift
= <Sum>  shift
=> ( <Sum> )  reduce
= ( <Sum> ) shift
=> ( <Sum> + <Sum>  ) reduce
=> ( <Sum> + 1  ) reduce
= ( <Sum> +  1 ) shift
= ( <Sum>  + 1 ) shift
=> ( 0  + 1 ) reduce
= ( ) shift
=  ( ) shift
11/10/2018

42. LR(i) Parsing Algorithm
7. If action = accept
Stop parsing, return success
8. If action = error,
Stop parsing, return failure
11/10/2018

43. Example
( )
11/10/2018

44. Example
( )
11/10/2018

45. Example
( )
11/10/2018

46. Example
<Sum>
( )
11/10/2018

47. Example
<Sum>
( )
11/10/2018

48. Example
<Sum>
( )
11/10/2018

49. Example
<Sum>
( )
11/10/2018

50. Example
<Sum>
( )
11/10/2018

51. Example
<Sum>
( )
11/10/2018

52. Example
<Sum>
( )
11/10/2018

53. Example
<Sum>
( )
11/10/2018

54. Example
<Sum>
( )
11/10/2018

55. Example
<Sum>
( )
11/10/2018

56. Example
<Sum>
( )
11/10/2018

57. Example
<Sum>
( )
11/10/2018

58. Shift-Reduce Conflicts
Problem: can’t decide whether the action for a state and input character should be shift or reduce
Caused by ambiguity in grammar
Usually caused by lack of associativity or precedence information in grammar
11/10/2018

59. -> <Sum>  + 1 + 0 shift -> <Sum> +  1 + 0 shift
Example: <Sum> = 0 | 1 | (<Sum>) | <Sum> + <Sum>
 shift
-> 0  reduce
-> <Sum>  shift
-> <Sum> +  shift
-> <Sum> + 1  reduce
-> <Sum> + <Sum>  + 0
11/10/2018

60. Example - cont Problem: shift or reduce?
You can shift-shift-reduce-reduce or reduce-shift-shift-reduce
Shift first - right associative
Reduce first- left associative
11/10/2018

61. Reduce - Reduce Conflicts
Problem: can’t decide between two different rules to reduce by
Again caused by ambiguity in grammar
Symptom: RHS of one production suffix of another
Requires examining grammar and rewriting it
Harder to solve than shift-reduce errors
11/10/2018

62. Example  abc shift a  bc shift ab  c shift abc 
S ::= A | aB A ::= abc B ::= bc
 abc shift
a  bc shift
ab  c shift
abc 
Problem: reduce by B ::= bc then by S ::= aB, or by A::= abc then S::A?
11/10/2018

63. Recursive Descent Parsing
Recursive descent parsers are a class of parsers derived fairly directly from BNF grammars
A recursive descent parser traces out a parse tree in top-down order, corresponding to a left-most derivation (LL - left-to-right scanning, leftmost derivation)
11/10/2018

64. Recursive Descent Parsing
Each nonterminal in the grammar has a subprogram associated with it; the subprogram parses all phrases that the nonterminal can generate
Each nonterminal in right-hand side of a rule corresponds to a recursive call to the associated subprogram
11/10/2018

65. Recursive Descent Parsing
Each subprogram must be able to decide how to begin parsing by looking at the left-most character in the string to be parsed
May do so directly, or indirectly by calling another parsing subprogram
Recursive descent parsers, like other top-down parsers, cannot be built from left-recursive grammars
Sometimes can modify grammar to suit
11/10/2018

66. Sample Grammar
<expr> ::= <term> | <term> + <expr>
| <term> - <expr>
<term> ::= <factor> | <factor> * <term>
| <factor> / <term>
<factor> ::= <id> | ( <expr> )
11/10/2018

67. Tokens as OCaml Types + - * / ( ) <id> Becomes an OCaml datatype
type token =
Id_token of string
| Left_parenthesis | Right_parenthesis
| Times_token | Divide_token
| Plus_token | Minus_token
11/10/2018

68. Parse Trees as Datatypes
<expr> ::= <term> | <term> + <expr>
| <term> - <expr>
type expr =
Term_as_Expr of term
| Plus_Expr of (term * expr)
| Minus_Expr of (term * expr)
11/10/2018

69. Parse Trees as Datatypes
<term> ::= <factor> | <factor> * <term>
| <factor> / <term>
and term =
Factor_as_Term of factor
| Mult_Term of (factor * term)
| Div_Term of (factor * term)
11/10/2018

70. Parse Trees as Datatypes
<factor> ::= <id> | ( <expr> )
and factor =
Id_as_Factor of string
| Parenthesized_Expr_as_Factor of expr
11/10/2018

71. Parsing Lists of Tokens
Will create three mutually recursive functions:
expr : token list -> (expr * token list)
term : token list -> (term * token list)
factor : token list -> (factor * token list)
Each parses what it can and gives back parse and remaining tokens
11/10/2018

72. <expr> ::= <term> [( + | - ) <expr> ]
Parsing an Expression
<expr> ::= <term> [( + | - ) <expr> ]
let rec expr tokens =
(match term tokens
with ( term_parse , tokens_after_term) ->
(match tokens_after_term
with( Plus_token :: tokens_after_plus) ->
11/10/2018

73. <expr> ::= <term> [( + | - ) <expr> ]
Parsing an Expression
<expr> ::= <term> [( + | - ) <expr> ]
let rec expr tokens =
(match term tokens
with ( term_parse , tokens_after_term) ->
(match tokens_after_term
with ( Plus_token :: tokens_after_plus) ->
11/10/2018

74. Parsing a Plus Expression
<expr> ::= <term> [( + | - ) <expr> ]
let rec expr tokens =
(match term tokens
with ( term_parse , tokens_after_term) ->
(match tokens_after_term
with ( Plus_token :: tokens_after_plus) ->
11/10/2018

75. Parsing a Plus Expression
<expr> ::= <term> [( + | - ) <expr> ]
let rec expr tokens =
(match term tokens
with ( term_parse , tokens_after_term) ->
(match tokens_after_term
with ( Plus_token :: tokens_after_plus) ->
11/10/2018

76. Parsing a Plus Expression
<expr> ::= <term> [( + | - ) <expr> ]
let rec expr tokens =
(match term tokens
with ( term_parse , tokens_after_term) ->
(match tokens_after_term
with ( Plus_token :: tokens_after_plus) ->
11/10/2018

77. Parsing a Plus Expression
<expr> ::= <term> + <expr>
(match expr tokens_after_plus
with ( expr_parse , tokens_after_expr) ->
( Plus_Expr ( term_parse , expr_parse ),
tokens_after_expr))
11/10/2018

78. Parsing a Plus Expression
<expr> ::= <term> + <expr>
(match expr tokens_after_plus
with ( expr_parse , tokens_after_expr) ->
( Plus_Expr ( term_parse , expr_parse ),
tokens_after_expr))
11/10/2018

79. Building Plus Expression Parse Tree
<expr> ::= <term> + <expr>
(match expr tokens_after_plus
with ( expr_parse , tokens_after_expr) ->
( Plus_Expr ( term_parse , expr_parse ),
tokens_after_expr))
11/10/2018

80. Parsing a Minus Expression
<expr> ::= <term> - <expr>
| ( Minus_token :: tokens_after_minus) ->
(match expr tokens_after_minus
with ( expr_parse , tokens_after_expr) ->
( Minus_Expr ( term_parse , expr_parse ),
tokens_after_expr))
11/10/2018

81. Parsing a Minus Expression
<expr> ::= <term> - <expr>
| ( Minus_token :: tokens_after_minus) ->
(match expr tokens_after_minus
with ( expr_parse , tokens_after_expr) ->
( Minus_Expr ( term_parse , expr_parse ),
tokens_after_expr))
11/10/2018

82. Parsing an Expression as a Term
<expr> ::= <term>
| _ -> (Term_as_Expr term_parse , tokens_after_term)))
Code for term is same except for replacing addition with multiplication and subtraction with division
11/10/2018

83. <factor> ::= <id>
Parsing Factor as Id
<factor> ::= <id>
and factor tokens =
(match tokens
with (Id_token id_name :: tokens_after_id) =
( Id_as_Factor id_name, tokens_after_id)
11/10/2018

84. Parsing Factor as Parenthesized Expression
<factor> ::= ( <expr> )
| factor ( Left_parenthesis :: tokens) =
(match expr tokens
with ( expr_parse , tokens_after_expr) ->
11/10/2018

85. Parsing Factor as Parenthesized Expression
<factor> ::= ( <expr> )
(match tokens_after_expr
with Right_parenthesis :: tokens_after_rparen ->
( Parenthesized_Expr_as_Factor expr_parse , tokens_after_rparen)
11/10/2018

86. Error Cases What if no matching right parenthesis?
| _ -> raise (Failure "No matching rparen") ))
What if no leading id or left parenthesis?
| _ -> raise (Failure "No id or lparen" ));;
11/10/2018

87. ( a + b ) * c - d
expr [Left_parenthesis; Id_token "a”; Plus_token; Id_token "b”; Right_parenthesis; Times_token; Id_token "c”; Minus_token; Id_token "d"];;
11/10/2018

88. ( a + b ) * c - d - : expr * token list = (Minus_Expr (Mult_Term
(Parenthesized_Expr_as_Factor
(Plus_Expr
(Factor_as_Term (Id_as_Factor "a"),
Term_as_Expr (Factor_as_Term (Id_as_Factor "b")))),
Factor_as_Term (Id_as_Factor "c")),
Term_as_Expr (Factor_as_Term (Id_as_Factor "d"))),
[])
11/10/2018

89. ( a + b ) * c – d <expr> <term> - <expr>
<factor> * <term> <term>
( <expr> ) <factor> <factor>
<term> + <expr> <id> <id>
<factor> <term> c d
<id> <factor>
a <id> b
11/10/2018

90. a + b * c – d
# expr [Id_token "a”; Plus_token; Id_token "b”; Times_token; Id_token "c”; Minus_token; Id_token "d"];;
- : expr * token list =
(Plus_Expr
(Factor_as_Term (Id_as_Factor "a"),
Minus_Expr
(Mult_Term (Id_as_Factor "b", Factor_as_Term (Id_as_Factor "c")),
Term_as_Expr (Factor_as_Term (Id_as_Factor "d")))),
[])
11/10/2018

91. a + b * c – d <expr> <term> + <expr>
<factor> < term> <expr>
<id> <factor> * <term> <term>
a <id> <factor> <factor>
b <id> <id>
c d
11/10/2018

92. ( a + b * c - d
# expr [Left_parenthesis; Id_token "a”; Plus_token; Id_token "b”; Times_token; Id_token "c”; Minus_token; Id_token "d"];;
Exception: Failure "No matching rparen".
Can’t parse because it was expecting a right parenthesis but it got to the end without finding one
11/10/2018

93. a + b ) * c – d (
expr [Id_token "a”; Plus_token; Id_token "b”; Right_parenthesis; Times_token; Id_token "c”; Minus_token; Id_token "d”; Left_parenthesis];;
- : expr * token list =
(Plus_Expr
(Factor_as_Term (Id_as_Factor "a"),
Term_as_Expr (Factor_as_Term (Id_as_Factor "b"))),
[Right_parenthesis; Times_token; Id_token "c"; Minus_token; Id_token "d"; Left_parenthesis])
11/10/2018

94. Parsing Whole String Q: How to guarantee whole string parses?
A: Check returned tokens empty
let parse tokens =
match expr tokens
with (expr_parse, []) -> expr_parse
| _ -> raise (Failure “No parse");;
Fixes <expr> as start symbol
11/10/2018

95. Streams in Place of Lists
More realistically, we don't want to create the entire list of tokens before we can start parsing
We want to generate one token at a time and use it to make one step in parsing
Can use (token * (unit -> token)) or (token * (unit -> token option))
in place of token list
11/10/2018

96. Problems for Recursive-Descent Parsing
Left Recursion:
A ::= Aw
translates to a subroutine that loops forever
Indirect Left Recursion:
A ::= Bw
B ::= Av
causes the same problem
11/10/2018

97. Problems for Recursive-Descent Parsing
Parser must always be able to choose the next action based only only the very next token
Pairwise Disjointedness Test: Can we always determine which rule (in the non-extended BNF) to choose based on just the first token
11/10/2018

98. Pairwise Disjointedness Test
For each rule
A ::= y
Calculate
FIRST (y) =
{a | y =>* aw}  { | if y =>* }
For each pair of rules A ::= y and A ::= z, require FIRST(y)  FIRST(z) = { }
11/10/2018

99. Example Grammar: <S> ::= <A> a <B> b
<B> ::= a <B> | a
FIRST (<A> b) = {b}
FIRST (b) = {b}
Rules for <A> not pairwise disjoint
11/10/2018

100. Eliminating Left Recursion
Rewrite grammar to shift left recursion to right recursion
Changes associativity
Given
<expr> ::= <expr> + <term> and
<expr> ::= <term>
Add new non-terminal <e> and replace above rules with
<expr> ::= <term><e>
<e> ::= + <term><e> | 
11/10/2018

101. <expr> ::= <term> [ ( + | - ) <expr> ]
Factoring Grammar
Test too strong: Can’t handle
<expr> ::= <term> [ ( + | - ) <expr> ]
Answer: Add new non-terminal and replace above rules by
<expr> ::= <term><e>
<e> ::= + <term><e>
<e> ::= - <term><e>
<e> ::= 
You are delaying the decision point
11/10/2018

102. Example Both <A> and <B> have problems:
<S> ::= <A> a <B> b
<A> ::= <A> b | b
<B> ::= a <B> | a
Transform grammar to:
<S> ::= <A> a <B> b
<A> ::-= b<A1>
<A1> :: b<A1> | 
<B> ::= a<B1>
<B1> ::= a<B1> | 
11/10/2018

103. Expresses the meaning of syntax Static semantics
Meaning based only on the form of the expression without executing it
Usually restricted to type checking / type inference
11/10/2018

104. Method of describing meaning of executing a program
Dynamic semantics
Method of describing meaning of executing a program
Several different types:
Operational Semantics
Axiomatic Semantics
Denotational Semantics
11/10/2018

105. Different languages better suited to different types of semantics
Dynamic Semantics
Different languages better suited to different types of semantics
Different types of semantics serve different purposes
11/10/2018

106. Operational Semantics
Start with a simple notion of machine
Describe how to execute (implement) programs of language on virtual machine, by describing how to execute each program statement (ie, following the structure of the program)
Meaning of program is how its execution changes the state of the machine
Useful as basis for implementations
11/10/2018

107. Axiomatic Semantics Also called Floyd-Hoare Logic
Based on formal logic (first order predicate calculus)
Axiomatic Semantics is a logical system built from axioms and inference rules
Mainly suited to simple imperative programming languages
11/10/2018

108. {Precondition} Program {Postcondition}
Axiomatic Semantics
Used to formally prove a property (post-condition) of the state (the values of the program variables) after the execution of program, assuming another property (pre-condition) of the state before execution
Written :
{Precondition} Program {Postcondition}
Source of idea of loop invariant
11/10/2018

109. Denotational Semantics
Construct a function M assigning a mathematical meaning to each program construct
Lambda calculus often used as the range of the meaning function
Meaning function is compositional: meaning of construct built from meaning of parts
Useful for proving properties of programs
11/10/2018

110. Natural Semantics
Aka Structural Operational Semantics, aka “Big Step Semantics”
Provide value for a program by rules and derivations, similar to type derivations
Rule conclusions look like
(C, m)  m’ or
(E, m)  v
11/10/2018

111. Simple Imperative Programming Language
I  Identifiers
N  Numerals
B ::= true | false | B & B | B or B | not B | E < E | E = E
E::= N | I | E + E | E * E | E - E | - E
C::= skip | C;C | I ::= E | if B then C else C fi | while B do C od
11/10/2018

112. Natural Semantics of Atomic Expressions
Identifiers: (I,m)  m(I)
Numerals are values: (N,m)  N
Booleans: (true,m)  true
(false ,m)  false
11/10/2018

113. Booleans: (B, m)  false (B, m)  true (B’, m)  b
(B & B’, m)  false (B & B’, m)  b
(B, m)  true (B, m)  false (B’, m)  b
(B or B’, m)  true (B or B’, m)  b
(B, m)  true (B, m)  false
(not B, m)  false (not B, m)  true
11/10/2018

114. Relations (E, m)  U (E’, m)  V U ~ V = b (E ~ E’, m)  b
By U ~ V = b, we mean does (the meaning of) the relation ~ hold on the meaning of U and V
May be specified by a mathematical expression/equation or rules matching U and V
11/10/2018

115. Arithmetic Expressions
(E, m)  U (E’, m)  V U op V = N
(E op E’, m)  N
where N is the specified value for U op V
11/10/2018

116. (I::=E,m)  m[I <-- V ]
Commands
Skip: (skip, m)  m
Assignment: (E,m)  V
(I::=E,m)  m[I <-- V ]
Sequencing: (C,m)  m’ (C’,m’)  m’’
(C;C’, m)  m’’
11/10/2018

117. (if B then C else C’ fi, m)  m’
If Then Else Command
(B,m)  true (C,m)  m’
(if B then C else C’ fi, m)  m’
(B,m)  false (C’,m)  m’
11/10/2018

118. (B,m)true (C,m)m’ (while B do C od, m’ )m’’
While Command
(B,m)  false
(while B do C od, m)  m
(B,m)true (C,m)m’ (while B do C od, m’ )m’’
(while B do C od, m)  m’’
11/10/2018

119. Example: If Then Else Rule
(2,{x->7})2 (3,{x->7}) 3
(2+3, {x->7})5
(x,{x->7})7 (5,{x->7}) (y:= 2 + 3, {x-> 7}
(x > 5, {x -> 7})true {x- >7, y->5}
(if x > 5 then y:= else y:=3 + 4 fi,
{x -> 7})  ?
11/10/2018

120. Example: If Then Else Rule
(2,{x->7})2 (3,{x->7}) 3
(2+3, {x->7})5
(x,{x->7})7 (5,{x->7}) (y:= 2 + 3, {x-> 7}
(x > 5, {x -> 7})? {x- >7, y->5}
(if x > 5 then y:= else y:=3 + 4 fi,
{x -> 7})  ? {x->7, y->5}
11/10/2018

121. Example: Arith Relation
(2,{x->7})2 (3,{x->7}) 3
? > ? = ? (2+3, {x->7})5
(x,{x->7})? (5,{x->7})? (y:= 2 + 3, {x-> 7}
(x > 5, {x -> 7})? {x- >7, y->5}
(if x > 5 then y:= else y:=3 + 4 fi,
{x -> 7})  ? {x->7, y->5}
11/10/2018

122. Example: Identifier(s)
(2,{x->7})2 (3,{x->7}) 3
7 > 5 = true (2+3, {x->7})5
(x,{x->7})7 (5,{x->7}) (y:= 2 + 3, {x-> 7}
(x > 5, {x -> 7})? {x- >7, y->5}
(if x > 5 then y:= else y:=3 + 4 fi,
{x -> 7})  ? {x->7, y->5}
11/10/2018

123. Example: Arith Relation
(2,{x->7})2 (3,{x->7}) 3
7 > 5 = true (2+3, {x->7})5
(x,{x->7})7 (5,{x->7}) (y:= 2 + 3, {x-> 7}
(x > 5, {x -> 7})true {x- >7, y->5}
(if x > 5 then y:= else y:=3 + 4 fi,
{x -> 7})  ? {x->7, y->5}
11/10/2018

124. Example: If Then Else Rule
(2,{x->7})2 (3,{x->7}) 3
7 > 5 = true (2+3, {x->7})5
(x,{x->7})7 (5,{x->7}) (y:= 2 + 3, {x-> 7}
(x > 5, {x -> 7})true  ?
(if x > 5 then y:= else y:=3 + 4 fi,
{x -> 7})  ? {x->7, y->5}
11/10/2018

125. Example: Assignment (2,{x->7})2 (3,{x->7}) 3
7 > 5 = true (2+3, {x->7})?
(x,{x->7})7 (5,{x->7}) (y:= 2 + 3, {x-> 7}
(x > 5, {x -> 7})true  ? {x- >7, y->5}
(if x > 5 then y:= else y:=3 + 4 fi,
{x -> 7})  ? {x->7, y->5}
11/10/2018

126. Example: Arith Op ? + ? = ? (2,{x->7})? (3,{x->7}) ?
7 > 5 = true (2+3, {x->7})?
(x,{x->7})7 (5,{x->7}) (y:= 2 + 3, {x-> 7}
(x > 5, {x -> 7})true ?
(if x > 5 then y:= else y:=3 + 4 fi,
{x -> 7})  ? {x->7, y->5}
11/10/2018

127. Example: Numerals 2 + 3 = 5 (2,{x->7})2 (3,{x->7}) 3
7 > 5 = true (2+3, {x->7})?
(x,{x->7})7 (5,{x->7}) (y:= 2 + 3, {x-> 7}
(x > 5, {x -> 7})true  ?{x->7, y->5}
(if x > 5 then y:= else y:=3 + 4 fi,
{x -> 7})  ? {x->7, y->5}
11/10/2018

128. Example: Arith Op 2 + 3 = 5 (2,{x->7})2 (3,{x->7}) 3
7 > 5 = true (2+3, {x->7})5
(x,{x->7})7 (5,{x->7}) (y:= 2 + 3, {x-> 7}
(x > 5, {x -> 7})true ? {x->7, y->5}
(if x > 5 then y:= else y:=3 + 4 fi,
{x -> 7})  ? {x->7, y->5}
11/10/2018

129. Example: Assignment 2 + 3 = 5 (2,{x->7})2 (3,{x->7}) 3
7 > 5 = true (2+3, {x->7})5
(x,{x->7})7 (5,{x->7}) (y:= 2 + 3, {x-> 7}
(x > 5, {x -> 7})true  {x->7, y->5}
(if x > 5 then y:= else y:=3 + 4 fi,
{x -> 7}) ? {x->7, y->5}
11/10/2018

130. Example: If Then Else Rule
2 + 3 = 5
(2,{x->7})2 (3,{x->7}) 3
7 > 5 = true (2+3, {x->7})5
(x,{x->7})7 (5,{x->7}) (y:= 2 + 3, {x-> 7}
(x > 5, {x -> 7})true  {x->7, y->5}
(if x > 5 then y:= else y:=3 + 4 fi,
{x -> 7})  {x->7, y->5}
11/10/2018

131. (E,m) v (C,m[I<-v])  m’
Let in Command
(E,m) v (C,m[I<-v])  m’
(let I = E in C, m)  m’ ’
Where m’’ (y) = m’ (y) for y I and
m’’ (I) = m (I) if m(I) is defined,
and m’’ (I) is undefined otherwise
11/10/2018

132. Example (x,{x->5})  5 (3,{x->5})  3 (x+3,{x->5})  8
(let x = 5 in (x:=x+3), {x -> 17})  ?
11/10/2018

133. Example (x,{x->5})  5 (3,{x->5})  3 (x+3,{x->5})  8
(let x = 5 in (x:=x+3), {x -> 17})  {x->17}
11/10/2018

134. Comment
Simple Imperative Programming Language introduces variables implicitly through assignment
The let-in command introduces scoped variables explictly
Clash of constructs apparent in awkward semantics
11/10/2018

135. Interpretation Versus Compilation
A compiler from language L1 to language L2 is a program that takes an L1 program and for each piece of code in L1 generates a piece of code in L2 of same meaning
An interpreter of L1 in L2 is an L2 program that executes the meaning of a given L1 program
Compiler would examine the body of a loop once; an interpreter would examine it every time the loop was executed
11/10/2018

136. Interpreter
An Interpreter represents the operational semantics of a language L1 (source language) in the language of implementation L2 (target language)
Built incrementally
Start with literals
Variables
Primitive operations
Evaluation of expressions
Evaluation of commands/declarations
11/10/2018

137. Interpreter Takes abstract syntax trees as input
In simple cases could be just strings
One procedure for each syntactic category (nonterminal)
eg one for expressions, another for commands
If Natural semantics used, tells how to compute final value from code
If Transition semantics used, tells how to compute next “state”
To get final value, put in a loop
11/10/2018

138. Natural Semantics Example
compute_exp (Var(v), m) = look_up v m
compute_exp (Int(n), _) = Num (n) …
compute_com(IfExp(b,c1,c2),m) =
if compute_exp (b,m) = Bool(true)
then compute_com (c1,m)
else compute_com (c2,m)
11/10/2018

139. Natural Semantics Example
compute_com(While(b,c), m) =
if compute_exp (b,m) = Bool(false)
then m
else compute_com
(While(b,c), compute_com(c,m))
May fail to terminate - exceed stack limits
Returns no useful information then
11/10/2018