Types and Programming Languages

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.
(12)3

3

1
2
3
We are going to define the meaning of expressions
by specifying how to evaluate them, giving the
expected results e.g. (if 12 then 3 else 4)1
evaluates to 5 .
The language contains many nonsensical
expressions such as (23)4 which we will
eliminate by means of a type system.
Its 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.
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(23) ? 6 if 24 then 1 else 3 ? 3
if we define ? in a suitable way. This
approach is called operational semantics.
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
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
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 12 else 4 ? 12 ? 3
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. 1true if 3 then 4 else 5
2 3
We will not define reductions - these expressions
are stuck. (Alternative 1true ? error where
error is a new expression.)
2. Sensible expressions which are more
complex e.g. 1(23) if 34 then 5
else 6 (12)(34)
We need to deal with these
9
Operational semantics of expressions
We define rules allowing part of an expression to
be reduced, maintaining the overall structure.
Addition
to reduce ef when e is not a value, first reduce
e by one step, giving e, then we have ef.
more concisely
if e ? e then ef ? ef
notation
general
IF we know that the reduction above the line is
possible THEN we conclude that the reduction
below the line is possible
10
Operational semantics of expressions
Exercise can we reduce 1(23) ? If so, what
do we get?
Our rule does not apply to 1(23) because 1 is
already a value and has no reductions. In
general, applying the rule repeatedly leads to an
expression of the form ve so we need a new
rule for expressions of this form.
Exercise what should the rule be?
Exercise how does (12)(23) reduce?
(12)(23) ? 3(23) ? 35 ? 8
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 12 then 34 else 12
reduce?
if 12 then 34 else 12 ? if false then 34
else 12 ? 12 ? 3
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.
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)
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)
Structural Operational Semantics due to Gordon
Plotkin.
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).
16
Deriving reductions
Formally the existence of each reduction is
justified by a derivation using the reduction
rules. For example, the reduction
if 12 then 34 else 12 ? if false then 34
else 12
is justified by
17
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. Thats 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.
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 doesnt this work in real
programming languages?
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 dont 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.
20
Reading
Pierce 3.1, 3.2, 3.4, 3.5
Exercises
Pierce 3.5.10, 3.5.18
Exercise sheet 1