1. Types and Programming Languages
Lecture 2
Simon Gay
Department of Computing Science
University of Glasgow
2006/07

2. Simple Expression Language
To introduce the main ideas of the course, we will begin by
looking at a simple language of expressions.
Abstract syntax of expressions e is defined by this grammar:
e ::= integer literal
| true | false
| e + e | e == e | e & e | if e then e else e
Abstract expressions should be understood as trees and we use
brackets to make this clear.
(1+2)+3 + + 3 1 2
2006/07
Types and Programming Languages Lecture 2 - Simon Gay

3. Types and Programming Languages Lecture 2 - Simon Gay
We are going to define the meaning of expressions by
specifying how to evaluate them, giving the expected results:
e.g. (if 1==2 then 3 else 4)+1 evaluates to 5 .
The language contains many nonsensical expressions such as
(2==3)+4 which we will eliminate by means of a type system.
It’s useful to separate out the integer and boolean literals: we
call them values, v. The grammar becomes
v ::= integer literal
| true | false
e ::= v
| e + e | e == e | e & e | if e then e else e
Sometimes we will refer to expressions as terms.
2006/07
Types and Programming Languages Lecture 2 - Simon Gay

4. Operational semantics of expressions
We define the semantics (meaning) of expressions by
formalizing step-by-step calculation.
e  e’ means that e is transformed into e’ by one step of
calculation or evaluation.
We say that e reduces to e’.  is called the reduction relation.
We write e * e’ if e is transformed into e’ by some number
of reduction steps (possibly zero).
Examples:
1+(2+3) * 6
if 2==4 then 1 else 3 * 3
if we define  in a suitable way.
This approach is called operational semantics.
2006/07
Types and Programming Languages Lecture 2 - Simon Gay

5. Operational semantics of expressions
We want + to represent addition. For values:
0 + 1  1
1 + 1  2
and so on…
In general:
u + v  w if u and v are integer literals and w is their sum
2006/07
Types and Programming Languages Lecture 2 - Simon Gay

6. Operational semantics of expressions
Similarly we want == to represent the equality test:
u == v  true if u and v are the same integer literal
u == v  false if u and v are different integer literals
We want & to represent logical conjunction:
u & v  w if u and v are boolean literals
and w is their logical conjunction
2006/07
Types and Programming Languages Lecture 2 - Simon Gay

7. Operational semantics of expressions
Conditional expressions are similar when the condition is a
value:
if true then e else e’  e
if false then e else e’  e’
Notice that in these cases we are not necessarily reducing
directly to a value - in general further steps are required.
Example:
if true then 1+2 else 4  1+2  3
2006/07
Types and Programming Languages Lecture 2 - Simon Gay

8. Operational semantics of expressions
Exercise: Give some examples of expressions for which we
have not yet specified reductions.
Two categories:
1. Expressions which we do not intend to have a value
e.g true if 3 then 4 else & 3
We will not define reductions - these expressions are stuck.
(Alternative: 1+true  error where error is a new expression.)
2. Sensible expressions which are more complex
e.g (2+3) if 3==4 then 5 else (1==2)&(3==4)
We need to deal with these…
2006/07
Types and Programming Languages Lecture 2 - Simon Gay

9. Operational semantics of expressions
We define rules allowing part of an expression to be reduced,
maintaining the overall structure.
Addition:
to reduce e+f when e is not a value, first reduce e by one step,
giving e’, then we have e’+f.
more concisely:
if e  e’ then e+f  e’+f
notation:
general:
IF we know that the reduction above the line is possible
THEN we conclude that the reduction below the line is possible
2006/07
Types and Programming Languages Lecture 2 - Simon Gay

10. Operational semantics of expressions
Exercise: can we reduce 1+(2+3) ? If so, what do we get?
Our rule does not apply to 1+(2+3) because 1 is already a value
and has no reductions. In general, applying the rule repeatedly
leads to an expression of the form v+e so we need a new rule
for expressions of this form.
Exercise: what should the rule be?
Exercise: how does (1+2)+(2+3) reduce?
(1+2)+(2+3)  3+(2+3)  3+5  8
2006/07
Types and Programming Languages Lecture 2 - Simon Gay

11. Operational semantics of expressions
The rules for + specify an evaluation order: evaluate the left
operand first. For + this is not very important, but for
conditionals it is:
Exercise: how does if 1==2 then 3+4 else 1+2 reduce?
if 1==2 then 3+4 else 1+2  if false then 3+4 else 1+2
 1+2  3
2006/07
Types and Programming Languages Lecture 2 - Simon Gay

12. Operational semantics of expressions
Exercise: what are the rest of the reduction rules for == ?
Similarly we can complete the rules for & :
Alternatively we can define shortcut evaluation:
and then we no longer need the u & v  w rule.
2006/07
Types and Programming Languages Lecture 2 - Simon Gay

13. Summary: operational semantics of expressions
u + v  w (R-SumLit) if u and v are integer literals
and w is their sum
(R-SumL)
(R-SumR)
u & v  w (R-AndLit) if u and v are boolean literals
and w is their conjunction
(R-AndL)
(R-AndR)
2006/07
Types and Programming Languages Lecture 2 - Simon Gay

14. Summary: operational semantics of expressions
u == v  true (R-EqT) if u and v are the same int. lit.
u == v  false (R-EqF) if u and v are different int. lits.
(R-EqL)
(R-EqR)
(R-IfT)
(R-IfF)
(R-IfC)
Structural Operational Semantics: due to Gordon Plotkin.
2006/07
Types and Programming Languages Lecture 2 - Simon Gay

15. Summary: operational semantics of expressions
The meaning of an expression e is calculated by reducing it:
until a stuck expression is reached.
Reductions are only possible if they can be derived from the
rules.
A stuck expression is either a value (representing the meaning
of the original expression) or a non-value which cannot be
reduced any further (representing a run-time error).
2006/07
Types and Programming Languages Lecture 2 - Simon Gay

16. Types and Programming Languages Lecture 2 - Simon Gay
Deriving reductions
Formally the existence of each reduction is justified by a
derivation using the reduction rules. For example, the reduction
if 1==2 then 3+4 else 1+2  if false then 3+4 else 1+2
is justified by
2006/07
Types and Programming Languages Lecture 2 - Simon Gay

17. Types and Programming Languages Lecture 2 - Simon Gay
What have we defined?
Let Expr be the set of all expressions.
We have defined a relation R on Expr: a subset of Expr  Expr.
When (e,f)  R we write e  f .
R is the smallest relation which is closed under the rules.
That’s what we mean by saying that reductions are only those
specified by the rules.
This is called an inductive definition. The rules are called
inference rules. A rule with no hypothesis (e.g. u == v  true)
is called an axiom.
2006/07
Types and Programming Languages Lecture 2 - Simon Gay

18. Avoiding run-time errors
We will say that e  Expr is valid if whenever it reduces to a
stuck expression s, s is a value.
Let Valid be the set of all valid expressions:
Valid  Expr. In fact, Valid  Expr. (If Valid = Expr: no problem!)
The Simple Expression Language is so simple that given
e  Expr we can work out whether or not e  Valid simply by
reducing e until we get stuck (which is bound to happen) and
then examining the stuck expression.
Exercise: why doesn’t this work in real programming languages?
2006/07
Types and Programming Languages Lecture 2 - Simon Gay

19. Avoiding run-time errors
We would like to define a set of safe expressions, Safe  Expr,
such that
given an expression e we can work out whether or not e  Safe without reducing e
Safe  Valid, so that if e  Safe then e is valid (has no run-time errors)
we expect that Safe  Valid but we want to make sure that the gap between Safe and Valid is not too large: if we adopt the principle of rejecting unsafe expressions, then we don’t want to reject too many valid expressions by mistake.
The idea is to define a type system, and then Safe will be the
set of expressions that are accepted by the typechecker.
2006/07
Types and Programming Languages Lecture 2 - Simon Gay

20. Types and Programming Languages Lecture 2 - Simon Gay
Reading
Pierce: 3.1, 3.2, 3.4, 3.5
Exercises
Pierce: ,
Exercise sheet 1
2006/07
Types and Programming Languages Lecture 2 - Simon Gay