Notes Q
Lecture on
Types
for Part II of the Computer Science Tripos Prof. Andrew M. Pitts University of Cambridge Computer Laboratory
c 2008 A. M. Pitts
First edition 1997. Revised 1999, 2000, 2001, 2002, 2004, 2005, 2006, 2007, 2008.
Contents
Learning Guide 1 2 Introduction ML Polymorphism 2.1 An ML type system . . . . . . . . . 2.2 Examples of type inference, by hand 2.3 Principal type schemes . . . . . . . 2.4 A type inference algorithm . . . . . 2.5 Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ii 1 7 8 17 22 24 28 31 31 36 38 39 39 42 50 52 59
3
Polymorphic Reference Types 3.1 The problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Restoring type soundness . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3 Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Polymorphic Lambda Calculus 4.1 From type schemes to polymorphic types 4.2 The PLC type system . . . . . . . . . . . 4.3 PLC type inference . . . . . . . . . . . . 4.4 Datatypes in PLC . . . . . . . . . . . . . 4.5 Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
5
Further Topics 63 5.1 Curry-Howard correspondence . . . . . . . . . . . . . . . . . . . . . . . . . 63 5.2 Dependent types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 5.3 Current areas of research . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 73
References
i
Learning Guide
These notes and slides are designed to accompany eight lectures on type systems for Part II of the Cambridge University Computer Science Tripos. The aim of this course is to show by example how type systems for programming languages can be dened and their properties developed, using techniques that were introduced in the Part IB course on Semantics of Programming Languages. So that course is a prerequisite (as, to a lesser extent, is the Part IB course on Foundations of Functional Programming.) We apply these techniques to a few selected topics centred mainly around the notion of polymorphism (or generics as it is known in the Java and C# communities). Formal systems and mathematical proof play an important role in this subjecta fact which is reected in the nature of the material presented here and in the kind of questions set on it in the Tripos. As well as learning some specic facts about the ML type system and the polymorphic lambda calculus, at the end of the course you should: appreciate how type systems can be used to constrain or describe the dynamic behaviour of programs be able to use a rule-based specication of a type system to infer typings and to establish type soundness results appreciate the expressive power of the polymorphic lambda calculus.
Tripos questions and exercises
A list of past Tripos questions back to 1993 that are relevant to the current course is available at www.cl.cam.ac.uk/teaching/exams/pastpapers/t-Types.html .1 In addition there are a few exercises at the end of most sections.
Recommended reading
The recent graduate-level text by Pierce (2002) covers much of the material presented in these notes (although not always in the same way), plus much else besides. It is highly recommended. The following addition material may be useful: Sections 23 (Cardelli 1987) introduces the ideas behind ML polymorphism and typechecking. One could also take a look in (Milner, Tofte, Harper, and MacQueen 1997) at the chapter dening the static semantics for the core language, although it does not make light reading! If you want more help understanding the material in Section 3 (Polymorphic Reference Types), try Section 1.1.2.1 (Value Polymorphism) of the SML97 Conversion Guide provided by the SML/NJ implementation of ML. (See the web page for this lecture course for a URL for this document.)
Watch out for a misprint in 1993 paper 9, question 11: in the notation of these notes, . should be dened to be ( ( ) ).
1
ii
Section 4 Read (Girard 1989) for an account by one of its creators of the polymorphic lambda calculus (Syst` me F), its relation to proof theory and much else besides. e
Note!
The material in these notes has been drawn from several different sources, including those mentioned above and previous versions of this course by the author and by others. Any errors are of course all my own work. Please let me know if you nd typos or possible errors: a list of corrections will be available from the course web page (follow links from www.cl.cam.ac.uk/teaching/ ), which also contains pointers to some other useful material. Please take time to complete the lecture(r) appraisal form for this course available at www.cl.cam.ac.uk/cgi-bin/lr/login .
Andrew Pitts [e-mail]
iii
iv
1 Introduction
One of the most helpful concepts in the whole of programming is the notion of type, used to classify the kinds of object which are manipulated. A signicant proportion of programming mistakes are detected by an implementation which does type-checking before it runs any program. Types provide a taxonomy which helps people to think and to communicate about programs. R. Milner, Computing Tomorrow (CUP, 1996), p264
This short course is about the use of types in programming languages. Types also play an important role in specication languages and in formal logics. Indeed types rst arose (in the work of Bertrand Russell (Russell 1903) around 1900) as a way of avoiding certain paradoxes in the logical foundations of mathematics. We will return to the interplay between types in programming languages and types in logic right at the end of the course. Many programming languages permit, or even require, the use of certain kinds of phrasestypes, structures, classes, interfaces, etcfor classifying expressions according to their structure (e.g. this expression is an array of character strings) and/or behaviour (e.g. this function takes an integer argument and returns a list of booleans). As indicated on Slide 1, a type system for a particular language is a formal specication of how such a classication of expressions into types is to be carried out.
The full title of this course is
Type Systems for Programming Languages
What are type systems and what are they good for? A type system is a tractable syntactic method for proving the absence of certain program behaviours by classifying phrases according to the kinds of values they compute
B. Pierce, Types and Programming Languages (MIT, 2002), p1
It is not an exaggeration to say that to date, type systems are the most important channel by which developments in theoretical computer science get applied in programming languages.
Slide 1
Here are some ways (summarised on Slide 2) in which type systems for programming languages get used: 1
2
1 INTRODUCTION
Uses of type systems
Detecting errors via type-checking, either statically (decidable errors
detected before programs are executed) or dynamically (typing errors detected during program execution).
Abstraction and support for structuring large systems. Documentation. Efciency. Whole-language safety.
Slide 2
Detecting errors Experience shows that a signicant proportion of programming mistakes (such as trying to multiply an integer by a string) can be detected by an implementation which does static type-checking, i.e. which checks for typing errors before it runs any program. Type systems used to implement such checks at compile-time necessarily involve decidable properties of program phrases, since otherwise the process of compilation is not guaranteed to terminate. (Recall the notion of (algorithmic) decidability from the CST IB Computation Theory course.) For example, in a Turing-powerful language (one that can code all partial recursive functions), it is undecidable whether an arbitrary arithmetic expression evaluates to 0 or not; hence static type-checking will not be able to eliminate all division by zero errors. Of course the more properties of program phrases a type systems can express the better and the development of the subject is partly a search for greater expressivity; but expressivity is constrained in theory by this decidability requirement, and is constrained in practice by questions of computational feasibility.
Abstraction and support for structuring large systems Type information is a crucial part of interfaces for modules and classes, allowing the whole to be to be designed independently of particular implementations of its parts. Type systems form the backbone of various module languages in which modules (structures) are assigned types which are interfaces (signatures).
3 Documentation Type information in procedure/function declarations and in module/class interfaces are a form of documentation, giving useful hints about intended use and behaviour. Static type-checking ensures that this kind of formal documentation keeps in step with changes to the program. Efciency Typing information can be used by a compilers to produce more efcient code. For example the rst use of types in computer science (in the 1950s) was to improve the efciency of numerical calculations in Fortran by distinguishing between integer and realvalue expressions. Many static analyses carried out by optimising compilers make use of specialised type systems: an example is the region inference used in the ML Kit Compiler to replace much garbage collection in the heap by stack-based memory management (Tofte and Talpin 1997).
Safety Informal denitions from the literature. A safe language is one that protects its own high-level abstractions [no matter what legal program we write in it]. A safe language is completely dened by its programmers manual [rather than which compiler we are using]. A safe language may have trapped errors [one that can be handled gracefully], but cant have untrapped errors [ones that cause unpredictable crashes].
Slide 3
Whole-language safety Slide 3 gives some informal denitions from the literature of what constitutes a safe language. Type systems are an important tool for designing safe languages, but in principle, an untyped language could be safe by virtue of performing certain checks at run-time. Since such checks generally hamper efciency, in practice very few untyped languages are safe; Cardelli (1997) cites LISP as an example of an untyped, safe language (and assembly language as the quintessential untyped, unsafe language). Although typed languages may use a combination of run- and compile-time checks to ensure safety, they usually emphasise the latter. In other words the ideal is to have a type system implementing
4
1 INTRODUCTION
algorithmically decidable checks used at compile-time to rule out all untrapped run-time errors (and some kinds of trapped ones as well). Of course some languages (such as C) employ types without any pretensions to safety.
Formal type systems
Constitute the precise, mathematical characterisation of informal type
systems (such as occur in the manuals of most typed languages.)
Basis for type soundness theorems: any well-typed program cannot
produce run-time errors (of some specied kind).
Can decouple specication of typing aspects of a language from
algorithmic concerns: the formal type system can dene typing independently of particular implementations of type-checking algorithms.
Slide 4
Some languages are designed to be safe by virtue of a type system, but turn out not to be because of unforeseen or unintended uses of certain combinations of their features (objectoriented languages seem particularly prone to this problem). We will see an example of this in Section 3, where we consider the combination of ML polymorphism with mutable references. Such difculties have been a great spur to the development of the formal mathematics and logic of type systems: one can only prove that a language is safe after its syntax and operational semantics have been formally specied. The main point of this course is to introduce a little of this formalism and illustrate its uses. Standard ML (Milner, Tofte, Harper, and MacQueen 1997) is the shining example of a full-scale language possessing a complete such specication and whose type soundness (cf. Slide 4) has been subject to proof.1
Standard ML is a sufciently large language that a fully formalised proof of its type safety is surely enormous and certainly requires machine-assistance to carry out. However, since the language design was semantically-driven and had type safety very much in mind, it is possible to give convincing, if semi-formal, proofs of type safety for large fragments of it.
1
5
Typical type system judgement is a relation between typing environments (), program phrases (M ) and type expressions ( ) that we write as
M :
and read as given the assignment of types to free identiers of M specied by type environment , then M has type . E.g.
f : int list int, b : bool
(if b then f nil else 3) : int
is a valid typing judgement about ML.
Slide 5
The study of formal type systems is part of structural operational semantics: to specify a formal type system one gives a number of axioms and rules for inductively generating the kind of assertion, or judgement, shown on Slide 5. Ideally the rules follow the structure of the phrase M , explaining how to type it in terms of how its subphrases can be types one speaks of syntax-directed sets of rules. It is worth pointing out that different language families use widely differing notations for typingsee Slide 6.
Once we have formalised a particular type system, we are in a position to prove results about type soundness (Slide 4) and the notions of type checking, typeability and type inference described on Slide 7. You have already seen some examples in the CST IB Semantics of Programming Languages course of formal type systems dened using inductive denitions generated by syntax-directed axioms and rules. In this course we look at more involved examples revolving around the notion of parametric polymorphism, to which we turn next.
6
1 INTRODUCTION
Notations for the typing relation foo has type bar ML-style (used in this course):
foo : bar
Haskell-style:
foo :: bar
C/Java-style:
bar foo
Slide 6
Type checking, typeability, and type inference Suppose given a type system for a programming language with judgements of the form
M : . M : derivable in
Type-checking problem: given , M , and , is the type system?
Typeability problem: given and M , is there any for which
M : is derivable in the type system?
Second problem is usually harder than the rst. Solving it usually involves devising a type inference algorithm computing a for each and M (or failing, if there is none).
Slide 7
2 ML Polymorphism
As indicated in the Introduction, static type-checking is regarded by many as an important aid to building large, well-structured, and reliable software systems. On the other hand, early forms of static typing, for example as found in Pascal, tended to hamper the ability to write generic code. For example, a procedure for sorting lists of one type of data could not be applied to lists of a different type of data. It is natural to want a polymorphic sorting procedureone which operates (uniformly) on lists of several different types. The potential signicance for programming languages of this phenomenon of polymorphism was rst emphasised by Strachey (1967), who identied several different varieties: see Slide 8. Here we will concentrate on parametric polymorphism. One way to get it is to make the type parameterisation an explicit part of the language syntax: we will see an example of this in Section 4. In this section we look at the implicit version of parametric polymorphism rst implemented in the ML family of languages (and subsequently adopted elsewhere, for example in forthcoming versions of Java and C# , where it is known as generics). ML phrases need contain little explicit type information: the type inference algorithm infers a most general type (scheme) for each well-formed phrase, from which all the other types of the phrase can be obtained by specialising type variables. These ideas should be familiar to you from your previous experience of Standard ML. The point of this section is to see how one gives a precise formalisation of a type system and its associated type inference algorithm for a small fragment of ML, called Mini-ML.
Polymorphism = has many types Overloading (or ad hoc polymorphism): same symbol denotes operations with unrelated implementations. (E.g. + might mean both
integer addition and string concatenation.)
Subsumption 1 violating safety.
<: 2 : any M1 : 1 can be used as M1 : 2 without
Parametric polymorphism (generics): same expression belongs to a family of structurally related types. (E.g. in SML, length function
fun length nil = 0 | length (x :: xs) = 1 + (length xs)
has type
list int for all types .)
Slide 8
7
8
2 ML POLYMORPHISM
Type variables and type schemes in Mini-ML To formalise statements like length has type
list int , for all types (i.e. variables for which types
it is natural to introduce type variables may be substituted) and write
length : ( list int). ( list int) is an example of a type scheme.
Slide 9
2.1 An ML type system
As indicated on Slide 9, to formalise parametric polymorphism, we have to introduce type variables. An interactive ML system will just display list int as the type of the length function (cf. Slide 8), leaving the universal quantication over implicit. However, when it comes to formalising the ML type system (as is done in the denition of the Standard ML static semantics in Milner, Tofte, Harper, and MacQueen 1997, chapter 4) it is necessary to make this universal quantication over types explicit in some way. The reason for this has to do with the typing of local declarations. Consider the example given on Slide 10. The expression (f true) :: (f nil) has type bool list, given some assumption about the type of the variable f . Two possible such assumptions are shown on Slide 11. Here we are interested in the second possibility since it leads to a type system with very useful properties. The particular grammar of ML types and type schemes that we will use is shown on Slide 12.
2.1 An ML type system
9
Polymorphism of let-bound variables in ML For example in
let f = x(x) in (f true) :: (f nil) x(x) has type for any type , and the variable f to which it is
bound is used polymorphically: - in (f - in (f
true), f has type bool bool nil), f has type bool list bool list list .
Overall, the expression has type bool
Slide 10
Ad hoc polymorphism:
: bool bool and f : bool list bool list , then (f true) :: (f nil) : bool list .
Parametric polymorphism: if f
if f
: ( ), then (f true) :: (f nil) : bool list .
Slide 11
10
2 ML POLYMORPHISM
Mini-ML types and type schemes Types
::= | | |
bool list
type variable type of booleans function type list type
where ranges over a xed, countably innite set TyVar. Type Schemes
::= A ( )
where A ranges over nite subsets of the set TyVar. When A
= {1 , . . . , n }, we write A ( ) as 1 , . . . , n ( ).
Slide 12
The following points about type schemes A ( ) should be noted. (i) The case when A is empty, A = { }, is allowed: { } ( ) is a well-formed type scheme. We will often regard the set of types as a subset of the set of type schemes by identifying the type with the type scheme { } ( ). (ii) Any occurrences in of a type variable A become bound in A ( ). Thus by denition, the free type variables of a type scheme A ( ) are all those type variables which occur in , but which are not in the nite set A. (For example the set of free type variables of ( ) is { }.) We call a type scheme A ( ) closed if it has no free type variables, that is, if A contains all the type variables occurring in . As usual for variable-binding constructs, we are not interested in the particular names of -bound type variables (since we may have to change them to avoid variable capture during substitution of types for free type variables). Therefore we will identify type schemes up to alpha-conversion of -bound type variables. For example, ( ) and ( ) determine the same alpha-equivalence class and will be used interchangeably. Of course the nite set ftv ( A ( )) of free type variables of a type scheme is well-dened up to alpha-conversion of bound type variables. Just as in (i) we identied Mini-ML types with trivial type schemes { } ( ), so we will sometimes write ftv ( )
2.1 An ML type system
11
for the nite set of type variables occurring in (of course all such occurrences are free, because Mini-ML types do not involve binding operations). (iii) ML type schemes are not ML types! So for example, ( ) is neither a wellformed Mini-ML type nor a well-formed Mini-ML type scheme.1 Rather, Mini-ML type schemes are a notation for families of types, parameterised by type variables. We get types from type schemes by substituting types for type variables, as we explain next.
The generalises relation between type schemes and types
= 1 , . . . , n ( ) generalises a type , and write if can be obtained from the type by simultaneously substituting some types i for the type variables i (i = 1, . . . , n): = [1 /1 , . . . , n /n ].
(N.B. The relation is unaffected by the particular choice of names of bound type variables in .)
We say a type scheme
The converse relation is called specialisation: a type is a specialisation of a type scheme if
.
Slide 13
Slide 13 gives some terminology and notation to do with substituting types for the bound type variables of a type scheme. The notion of a type scheme generalising a type will feature in the way variables are assigned types in the Mini-ML type system that we are going to dene in this section. Example 2.1.1. Some simple examples of generalisation: ( ) ( ) ( ) However ( )
1
bool bool list list ( ) ( ). ( ) .
The step of making type schemes rst class types will be taken in Section 4.
12
2 ML POLYMORPHISM
This is because in a substitution [ /], by denition we have to replace all occurrences in of the type variable by . Thus when = , there is no type for which [ /] is the type ( ) . (Simply because in the syntax tree of [ /] = , the two subtrees below the outermost constructor are equal (namely to ), whereas this is false of ( ) .) Another example: 1 , 2 (1 2 ) However 1 (1 2 ) list bool because 2 is a free type variable in the type scheme 1 (1 2 ) and so cannot be substituted for during specialisation. list bool .
Mini-ML typing judgement takes the form
M : where
the typing environment is a nite function from variables to type
schemes. (We write
= {x1 : 1 , . . . , xn : n } to indicate that has domain of denition dom() = {x1 , . . . , xn } and maps each xi to the type scheme i for i = 1..n.)
M is an Mini-ML expression is an Mini-ML type.
Slide 14
Slide 14 gives the form of typing judgement we will use to illustrate ML polymorphism and type inference. Just as we only consider a small subset of ML types, we restrict attention to typings for a small subset of ML expressions, M , generated by the grammar on Slide 15. We use a non-standard syntax compared with the denition in (Milner, Tofte, Harper, and MacQueen 1997). For example we write x(M ) for fn x => M and let x = M1 in M2 for let val x = M1 in M2 end. Furthermore we call the symbol x occurring in these expressions a variable rather than a (value) identier. As usual, the free variables of x(M ) are those of M , except for x. In the expression let x = M1 in M2 , any free occurrences of the variable x in M2 become bound in the let-expression. Similarly, in the expression
2.1 An ML type system
13
case M1 of nil => M2 | x1 :: x2 => M3 , any free occurrences of the variables x1 and x2 in M3 become bound in the case-expression. The axioms and rules inductively generating the Mini-ML typing relation for these expressions are given on Slides 1617.
Mini-ML expressions, M
::= | | | | | | | | |
x true false if M then M else M x(M ) MM let x = M in M nil M :: M case M of nil => M | x :: x => M
variable boolean values
conditional function abstraction function application local declaration nil list list cons case expression
Slide 15
Note the following points about the type system dened on Slides 1619. (i) Given a type environment we write , x : to indicate a typing environment with domain dom() {x}, mapping x to and otherwise mapping like . When we use this notation it will almost always be the case that x dom() (cf. rules (fn), (let) / and (case)). (ii) In rule (fn) we use , x : 1 as an abbreviation for , x : { } (1 ). Similarly, in rule (case), , x1 : 1 , x2 : 1 list really means , x1 : { } (1 ), x2 : { } (1 list). (Recall that by denition, a typing environment has to map variables to type schemes, rather than to types.) (iii) In rule (let) the notation ftv () means the set of all type variables occurring free in some type scheme assigned in . (For example, if = {x1 : 1 , . . . , xn : n }, then ftv () = ftv (1 ) ftv (n ).) Thus the set A = ftv ( ) ftv () used in that rule consists of all type variables in that do not occur freely in any type scheme assigned in .
14
2 ML POLYMORPHISM
Mini-ML type system, I
(var (bool)
)
x : if (x : ) and
B : bool if B {true, false} M1 : bool M2 : M3 :
(if )
if M1 then M2 else M3 :
Slide 16
Mini-ML type system, II
(nil)
nil : list M1 : M2 : list
(cons)
M1 :: M2 : list M2 : 2 M3 : 2
M1 : 1 list , x1 : 1 , x2 : 1 list
(case)
case M1 of nil => M2 |x1 :: x2 => M3 : 2
x1 , x2 / dom() and x1 = x2
if
Slide 17
2.1 An ML type system
15
Mini-ML type system, III
(fn)
, x : 1
M : 2
x(M ) : 1 2 M1 : 1 2
if x
dom() /
(app)
M2 : 1
M1 M2 : 2
Slide 18
Mini-ML type system, IV
M1 : , x : A ( ) M2 :
(let)
let x = M1 in M2 :
dom() and / A = ftv ( ) ftv ()
if x
Slide 19
16
2 ML POLYMORPHISM
Assigning type schemes to Mini-ML expressions Given a type scheme
= A ( ), write M : M : is derivable from the axiom
if A
= ftv ( ) ftv () and
and rules on Slides 1619. When
M : and say that the (necessarily closedsee Exercise 2.5.2) expression M is typeable in Mini-ML with type scheme .
= { } we just write
M : for { }
Slide 20
As usual, the axioms and rules on Slides 1619 are schematic: , M , and stand for any well-formed type environment, expression, and type. The axiom and rules are used to inductively generate the typing relationa subset of all possible triples M : . We say that a particular triple M : is derivable (or provable, or valid) in the type system if there is a proof of it using the axioms and rules. Thus the typing relation consists of exactly those triples for which there is such a proof. In fact we often use the typing relation to assign not just types, but also type schemes to Mini-ML expressions, as described on Slide 20. Example 2.1.2. We verify that the example of polymorphism of let-bound variables given on Slide 10 has the type claimed there, i.e. that let f = x(x) in (f true) :: (f nil) : bool list. holds. Proof. First note that (1) {} x(x) : ( ), as witnessed by the following proof: x: x: (var ) using { } () (fn) ) we have
x(x) :
Next note that since ( )
bool bool , by (var
f : ( )
f : bool bool .
2.2 Examples of type inference, by hand
By (bool) we also have f : ( ) true : bool
17
and applying the rule (app) to these two judgements we get
(2)
f : ( )
f true : bool .
Similarly, using (app) on (var
) and (nil), we have
(3)
f : ( )
f nil : bool list.
Applying rule (cons) to (2) and (3) we get
f : ( )
(f true) :: (f nil) : bool list.
Finally we can apply rule (let) to this and (1) to conclude
{}
let f = x(x) in (f true) :: (f nil) : bool list
as required.
2.2 Examples of type inference, by hand
As for the full ML type system, for the type system we have just introduced the typeability problem (Slide 7) turns out to be decidable. Moreover, among all the possible type schemes a given closed Mini-ML expression may possess, there is a most general oneone from which all the others can be obtained by substitution. Before showing why this is the case, we give some specic examples of type inference in this type system.
18
2 ML POLYMORPHISM
Two examples involving self-application
M = let f = x1 (x2 (x1 )) in f f M = (f (f f )) x1 (x2 (x1 ))
Are M and M typeable in the Mini-ML type system?
def
def
Slide 21
Given a typing environment and an expression M , how can we decide whether or not there is a type scheme for which M : holds? We are aided in this task by the syntaxdirected (or structural) nature of the axioms and rules: if M : A ( ) is derivable, i.e. if A = ftv ( ) ftv () and M : is derivable from Slides 1619, then the outermost form of the expression M dictates which must be the last axiom or rule used in the proof of M : . Consequently, as we try to build a proof of a typing judgement M : from the bottom up, the structure of the expression M determines the shape of the tree together with which rules are used at its nodes and which axioms at its leaves. For example, for the particular expression M given on Slide 21, any proof of {} M : 1 from the axioms and rules, has to look like the tree given in Figure 1. Node (C0) is supposed to be an instance of the (let) rule; nodes (C1) and (C2) instances of the (fn) rule; leaves (C3), (C5), and (C6) instances of the (var ) axiom; and node (C4) an instance of the (app) rule. For these to be valid instances the constraints (C0)(C6) listed on Slide 22 have to be satised.
2.2 Examples of type inference, by hand
19
x1 : 3 , x2 : 5 x1 : 3 {}
x1 : 6
(C3) (C2) (C1) f : A (2 ) f : 7 (C5) f : A (2 ) f f : 1 (C0) f : 8 (C6) (C4)
x2 (x1 ) : 4
x1 (x2 (x1 )) : 2 {}
f : A (2 )
let f = x1 (x2 (x1 )) in f f : 1
Figure 1: Skeleton proof tree for let f = x1 (x2 (x1 )) in f f
Constraints generated while inferring a type for
let f = x1 (x2 (x1 )) in f f
(C0) (C1) (C2) (C3) (C4) (C5) (C6)
A = ftv (2 ) 2 = 3 4 4 = 5 6 { } (3 ) 6 , i.e. 3 = 6 7 = 8 1 A (2 ) A (2 ) 7 8
Slide 22
Thus M is typeable if and only if we can nd types 1 , . . . , 8 satisfying the constraints on Slide 22. First note that they imply 2 = 3 4 = 3 (5 6 ) = 6 (5 6 ). So let us take 5 , 6 to be type variables, say 2 , 1 respectively. Hence by (C0), A = ftv (2 ) = ftv (1 (2 1 )) = {1 , 2 }. Then (C4), (C5) and (C6) require that 1 , 2 (1 (2 1 )) 8 1 and 1 , 2 (1 (2 1 )) 8 .
(C1) (C2) (C3)
20 In other words there have to be some types 9 , . . . , 12 such that (C7) (C8) Now (C7) can only hold if 9 = 8 and hence and 10 9 = 1 9 (10 9 ) = 8 1 11 (12 11 ) = 8 .
2 ML POLYMORPHISM
1 = 10 9 = 10 8 = 10 (11 (12 11 )). with 10 , 11 , 12 otherwise unconstrained. So if we take them to be type variables 3 , 4 , 5 respectively, all in all, we can satisfy all the constraints on Slide 22 by dening A = {1 , 2 } 1 = 3 (4 (5 4 )) 2 = 1 (2 1 ) 3 = 1 4 = 2 1 5 = 2 6 = 1 7 = (4 (5 4 )) (3 (4 (5 4 ))) 8 = 4 (5 4 ). With these choices, Figure 1 becomes a valid proof of {} let f = x1 (x2 (x1 )) in f f : 3 (4 (5 4 ))
(C8)
from the typing axioms and rules on Slides 1619, i.e. we do have (4) let f = x1 (x2 (x1 )) in f f : 3 , 4 , 5 (3 (4 (5 4 )))
If we go through the same type inference process for the expression M on Slide 21 we generate a tree and set of constraints as in Figure 2. These imply in particular that 7 = 4 = 6 = 7 5 . But there are no types 5 , 7 satisfying 7 = 7 5 , because 7 5 contains at least one more symbol than does 7 . So we conclude that (f (f f )) x1 (x2 (x1 )) is not typeable within the ML type system.
(C13) (C12) (C11)
2.2 Examples of type inference, by hand
21
f : 4
f : 6 {}
(C12)
f : 4
f : 7
(C13) (C11)
x1 : 8 , x2 : 10 x1 : 8
x1 : 11
(C16) (C15) (C14) (C9)
f : 4
f f : 5
f (f f ) : 2 {}
(C10)
x2 (x1 ) : 9
{ } : x1 (x2 (x1 )) : 3
(f (f f )) x1 (x2 (x1 )) : 1
Constraints: (C9) (C10) (C11) (C12) (C13) (C14) (C15) (C16) { } (11 ) 2 = 3 1 2 = 4 5 6 = 7 5 { } (4 ) 6 , i.e. 4 = 6 { } (4 ) 7 , i.e. 4 = 7 3 = 8 9 9 = 10 11 8 , i.e. 11 = 8
Figure 2: Skeleton proof tree and constraints for (f (f f )) x1 (x2 (x1 ))
22
2 ML POLYMORPHISM
2.3 Principal type schemes
The type scheme 3 , 4 , 5 (3 (4 (5 4 ))) not only satises (4), it is in fact the most general, or principal type scheme for let f = x1 (x2 (x1 )) in f f , as dened on Slide 23. It is worth pointing out that in the presence of (a), the converse of condition (b) on Slide 23 holds: if M : A ( ) and A ( ) , then M : A ( ) (where A = ftv ( )). This is a consequence of the substitution property of valid Mini-ML typing judgements given in Exercise 2.5.6. Slide 24 gives the main result about the Mini-ML typeability problem. It was rst proved for a simple type system without polymorphic let-expressions by Hindley (1969) and extended to the full system by Damas and Milner (1982).
Principal type schemes for closed expressions A closed type scheme A ( ) is the principal type scheme of a closed Mini-ML expression M if (a)
M : A ( ) ( ),
if
(b) for any other closed type scheme A
M : A ( ), then A ( )
Slide 23
Remark 2.3.1 (Complexity of the type checking algorithm). Although typeability is decidable, it is known to be exponential-time complete. Furthermore, the principal type scheme of an expression can be exponentially larger than the expression itself, even if the type involved is represented efciently as a directed acyclic graph. More precisely, the time taken to decide typeability and the space needed to display the principal type are both exponential in the number of nested lets in the expression. For example the expression on Slide 25 (taken from Mairson 1990) has a principal type scheme which would take hundreds of pages to print out. It seems that such pathology does not arise naturally, and that the type checking phase of an ML compiler is not a bottle neck in practice. For more details about the complexity of ML type inference see (Mitchell 1996, Section 11.3.5).
2.3 Principal type schemes
23
Theorem (Hindley; Damas-Milner) If the closed Mini-ML expression M is typeable (i.e.
M : holds for some type scheme ), then there is a principal type scheme for M .
Indeed, there is an algorithm which, given any M as input, decides whether or not it is typeable and returns a principal type scheme if it is.
Slide 24
An ML expression with a principal type scheme hundreds of pages long
let pair = x(y(z(z x y))) in let x1 = y(pair y y) in let x2 = y(x1 (x1 y)) in let x3 = y(x2 (x2 y)) in let x4 = y(x3 (x3 y)) in let x5 = y(x4 (x4 y)) in x5 (y(y))
(Taken from Mairson 1990.)
Slide 25
24
2 ML POLYMORPHISM
2.4 A type inference algorithm
The aim of this subsection is to sketch the proof of the Hindley-Damas-Milner theorem stated on Slide 24, by describing an algorithm, pt, for deciding typeability and returning a most general type scheme. pt is dened recursively, following structure of expressions (and its termination is proved by induction on the structure of expressions). As the examples in Section 2.2 should suggest, the algorithm depends crucially upon unicationthe fact that the solvability of a nite set of equations between algebraic terms is decidable and that a most general solution exists, if any does. This fact was discovered by Robinson (1965) and has been a key ingredient in several logic-related areas of computer science (automated theorem proving, logic programming, and of course type systems, to name three). The form of unication algorithm, mgu, we need here is specied on Slide 26. Although we wont bother to give an implementation of mgu here (see for example (Rydeheard and Burstall 1988, Chapter 8), (Mitchell 1996, Section 11.2.2), or (Aho, Sethi, and Ullman 1986, Section 6.7) for more details), we do need to explain the notation for type substitutions introduced on Slide 26.
Unication of ML types There is an algorithm mgu which when input two Mini-ML types 1 and
2 decides whether 1 and 2 are uniable, i.e. whether there exists a type-substitution S Sub with
(a)
S(1 ) = S(2 ).
Moreover, if they are uniable, mgu(1 , 2 ) returns the most general unier an S satisfying both (a) and (b) for all S
Sub, if S (1 ) = S (2 ), then S = T S for some T Sub.
= FAIL if (and only if) 1 and 2 are not uniable.
By convention mgu(1 , 2 )
Slide 26
Denition 2.4.1 (Type substitutions). A type substitution S is a (totally dened) function from type variables to Mini-ML types with the property that S() = for all but nitely many . We write Sub for the set of all such functions. The domain of S Sub is the nite set of variables def dom(S) = { TyVar | S() = } Given a type substitution S, the effect of applying the substitution to a type is written
2.4 A type inference algorithm
25
S ; thus if dom(S) = {1 , . . . , n } and S(i ) is the type i for each i = 1..n, then S( ) is the type resulting from simultaneously replacing each occurrence of i in with i (for all i = 1..n), i.e.
S = [1 /1 , . . . , n /n ]
using the notation for substitution from Slide 13. Notwithstanding the notation on the right hand side of the above equation, we prefer to write the application of a type substitution function S on the left of the type to which it is being applied.1 As a result, the composition T S of two type substitutions S, T Sub means rst apply S and then T . Thus by denition T S is the function mapping each type variable to the type T (S()) (apply the type substitution T to the type S()). Note that the function T S does satisfy the niteness condition required of a substitution and we do have T S Sub; indeed, dom(T S) dom(T ) dom(S). More generally, if dom(S) = {1 , . . . , n } and is an Mini-ML type scheme, then S will denote the result of the (capture-avoiding2 ) substitution of S(i ) for each free occurrence of i in (for i = 1..n).
Even though we are ultimately interested in the typeability of closed expressions, since the algorithm pt descends recursively through the subexpressions of the input expression, inevitably it has to generate typings for expressions with free variables. Hence we have to dene the notions of typeability and principal type scheme for open expressions in the presence of a non-empty typing environment. This is done on Slide 27. For the denitions on that slide to be reasonable, we need some properties of the typing relation with respect to type substitutions and specialisation. These are stated on Slide 28; we leave the proofs as exercises (see Exercise 2.5.6). To compute principal type schemes it sufces to compute principal solutions in the sense of Slide 27: for if M is in fact closed, then any principal solution (S, ) for the typing problem { } M : ? has the property that is a principal type scheme for M in the sense of Slide 23 (see Exercise 2.5.5).
i.e. we write S rather than S as in the Part IB Logic and Proof course. Since we identify type schemes up to renaming their -bound type variables, we always assume the bound type variables in are different from any type variables in the types S(i ).
2
1
26
2 ML POLYMORPHISM
Principal type schemes for open expressions A solution for the typing problem
M : ? is a pair (S, ) consisting of a type substitution S and a type scheme satisfying S M :
(where S
= {x1 : S 1 , . . . , xn : S n }, if = {x1 : 1 , . . . , xn : n }).
Such a solution is principal if given any other, (S
, ), there is some
T Sub with T S = S and T ()
[For type schemes and , with
.
= A ( ) say, we dene to mean A ftv () = {} and .]
Slide 27
Properties of the Mini-ML typing relation
If S If
M : , then for any type substitution S Sub M : S . M : and , then M :.
Slide 28
2.4 A type inference algorithm
27
Specication for the principal typing algorithm, pt
pt operates on typing problems M : ? (consisting of a typing environment and a Mini-ML expression M ). It returns either a pair (S, ) consisting of a type substitution S Sub and a Mini-ML type , or the exception FAIL. If M : ? has a solution (cf. Slide 27), then pt( M : ?) returns (S, ) for some S and ; moreover, setting A = (ftv ( ) ftv (S )), then (S, A ( )) is a principal solution for the problem M : ?. M : ? has no solution, then pt( M : ?) returns FAIL.
If
Slide 29
Slide 29 sets out in more detail what is required of the principal typing algorithm, pt. One possible algorithm in somewhat informal pseudocode (and leaving out the cases for nil, cons, and case-expressions) is sketched on Slide 30 and in Figure 3.1 Note the following points about the denitions on Slide 30 and in Figure 3: (i) We implicitly assume that all bound variables in expressions and bound type variables in type schemes are distinct from each other and from any other variables in context. So, for example, the clause for function abstractions tacitly assumes that x dom(); / and the clause for variables assumes that A ftv () = { }. (ii) The type substitution Id occurring in the clauses for variables and booleans is the identity substitution which maps each type variable to itself. (iii) We have not given the clauses of the denition for nil, cons, and case-expressions (Exercise 2.5.4). (iv) We do not give the proof that the denition in Figure 3 is correct (i.e. meets the specication on Slide 29): but see Exercise 2.5.7. The correctness of the algorithm
A complete implementation of this algorithm in Fresh OCaml (www.freshml.org/foc/) can be found on the course web page. The Fresh OCaml code is remarkably close to the informal pseudocode given here, because of Fresh OCamls sophisticated facilities for dealing with binding operations and fresh names.
1
28
2 ML POLYMORPHISM
depends upon an important property of Mini-ML typing, namely that it is respected by the operation of substituting types for type variables: see Exercise 2.5.6.
Some of the clauses in a denition of pt Function abstractions:
pt(
x(M ) : ?) =
def
let = fresh in let (S, ) = pt(, x :
Function applications:
M : ?) in (S, S() )
def
pt( M1 M2 : ?) = let (S1 , 1 ) = pt( M1 : ?) in let (S2 , 2 ) = pt(S1 M2 : ?) in let = fresh in let S3 = mgu(S2 1 , 2 ) in (S3 S2 S1 , S3 ())
Slide 30
More efcient algorithms make use of a different approach to substitution and unication, based on equivalence relations on directed acylic graphs and union-nd algorithms: see (R my 2002, Sect. 2.4.2), for example. In that reference, and also in Pierces book (Pierce e 2002, Section 22.3), you will see an approach to type inference algorithms that views them as part of the more general problem of generating and solving constraint problems. This seems to be a fruitful viewpoint, because it accommodates a wide range of different type inference problems.
2.5 Exercises
Exercise 2.5.1. Here are some type checking problems, in the sense of Slide 7. Prove the following typings hold for the Mini-ML type system: x(x :: nil) : ( list) x(case x of nil => true | x1 :: x2 => false) : ( list bool ) x1 (x2 (x1 )) : 1 , 2 (1 (2 1 )) let f = x1 (x2 (x1 )) in f f : 1 , 2 , 3 (1 (2 (3 2 ))).
2.5 Exercises
29
Variables: pt(
x : ?) = let A ( ) = (x) in (Id , )
def
def
let-Expressions: pt( let x = M1 in M2 : ?) = let (S1 , 1 ) = pt( M1 : ?) in let A = ftv (1 ) ftv (S1 ) in let (S2 , 2 ) = pt(S1 , x : A (1 ) M2 : ?) in (S2 S1 , 2 ) Booleans (B = true, false): pt( B : ?) = (Id , bool )
def def
Conditionals: pt( if M1 then M2 else M3 : ?) = let (S1 , 1 ) = pt( M1 : ?) in let S2 = mgu(1 , bool ) in let (S3 , 3 ) = pt(S2 S1 M2 : ?) in let (S4 , 4 ) = pt(S3 S2 S1 M3 : ?) in let S5 = mgu(S4 3 , 4 ) in (S5 S4 S3 S2 S1 , S5 4 )
Figure 3: Some of the clauses in a denition of pt Exercise 2.5.2. Show that if { } M : is provable, then M must be closed, i.e. have no free variables. [Hint: use rule induction for the rules on Slides 1619 to show that the provable typing judgements, M : , all have the property that fv (M ) dom().] Exercise 2.5.3. Let and be Mini-ML type schemes. Show that the relation dened on Slide 27 holds if and only if ( ).
[Hint: use the following property of simultaneous substitution: ( [1 /1 , . . . , n /n ])[ / ] = [1 [ / ]/1 , . . . , n [ / ]/n ] which holds provided the type variables do not occur in .] Exercise 2.5.4. Try to augment the denition of pt on Slide 30 and in Figure 3 with clauses for nil, cons, and case-expressions. Exercise 2.5.5. Suppose M is a closed expression and that (S, ) is a principal solution for the typing problem { } M : ? in the sense of Slide 27. Show that must be a principal type scheme for M in the sense of Slide 23. Exercise 2.5.6. Show that if M : is provable and S Sub is a type substitution, then S M : S is also provable. Exercise 2.5.7. [hard] Try to give some of the proof that the denition in Figure 3 meets the specication on Slide 29. For example, try to prove that if (pt( Mi : ?) has correct properties)
30 for i = 1, 2, then (pt(
2 ML POLYMORPHISM
M1 M2 : ?) has correct properties).
(Why is it necessary to build the quantication over into the inductive hypotheses?)
31
3 Polymorphic Reference Types
3.1 The problem
Recall from the Introduction that an important purpose of type systems is to provide safety (Slide 3) via type soundness results (Slide 4). Even if a programming language is intended to be safe by virtue of its type system, it can happen that separate features of the language, each desirable in themselves, can combine in unexpected ways to produce an unsound type system. In this section we look at an example of this which occurred in the development of the ML family of languages. The two features which combine in a nasty way are: MLs style of implicitly typed let-bound polymorphism, and reference types. We have already treated the rst topic in Section 2. The second concerns MLs imperative features, which are based upon the ability to dynamically create locally scoped storage locations which can be written to and read from. We begin by giving the syntax and typing rules for this. We augment the grammar for Mini-ML types (Slide 12) with a unit type (a type with a single value) and reference types; and correspondingly, we augment the grammar for Mini-ML expressions (Slide 15) with a unit value, and operations for reference creation, dereferencing and assignment. These additions are shown on Slide 31. We call the resulting language Midi-ML. The typing rules for these new forms of expression are given on Slide 32.
ML types and expressions for mutable references
::= . . . | unit | ref ::= | | | | ... () ref M !M M := M
unit type reference type.
M
unit value reference creation dereference assignment
Slide 31
32
3 POLYMORPHIC REFERENCE TYPES
Midi-MLs extra typing rules (unit)
() : unit M : ref M : ref M : ref !M : M1 : ref M2 :
(ref )
(get)
(set)
M1 := M2 : unit
Slide 32
Example 3.1.1 The expression
let r = ref x(x) in let u = (r := x (ref !x )) in (!r)()
has type unit .
Slide 33
3.1 The problem
33
Example 3.1.1. Here is an example of the typing rules on Slide 32 in use. The expression given on Slide 33 has type unit. Proof. This can be deduced by applying the (let) rule (Slide 19) to the judgements {} ref x(x) : ( ) ref let u = (r := x (ref !x )) in (!r)() : unit.
r : (( ) ref )
The rst of these judgements has the following proof: x: {} {} x: (var ) (ref)
x(x) :
(fn)
ref x(x) : ( ) ref
The second judgement can be proved by applying the (let) rule to (5) (6) r : (( ) ref ) r := x (ref !x ) : unit (!r)() : unit
r : (( ) ref ), u : unit
Writing for the typing environment {r : (( ) ref )}, the proof of (5) is , x : ref , x : ref (var ) , x : ref x : ref !x : (var (get) (ref) (fn) (set) )
ref !x : ref
r : ( ref ref ) ref
x (ref !x ) : ref ref
r := x (ref !x ) : unit
while the proof of (6) is , u : unit , u : unit r : (unit unit) ref !r : unit unit , u : unit (var (get) ) , u : unit () : unit (unit) (app)
(!r)() : unit
Although the typing rules for references seem fairly innocuous, they combine with the previous typing rules, and with the (let) rule in particular, to produce a type system for which type soundness fails with respect to MLs operational semantics. For consider what happens when the expression on Slide 33, call it M , is evaluated. Evaluation of the outermost let-binding in M creates a fresh storage location bound to r and containing the value x(x). Evaluation of the second let-binding updates the
34
3 POLYMORPHIC REFERENCE TYPES
contents of r to the value x (ref !x ) and binds the unit value to u. (Since the variable u does not occur in its body, M s innermost let-expression is just a way of expressing the sequence (r := x (ref !x )); (!r)() in the fragment of ML that we are using for illustrative purposes.) Next (!r)() is evaluated. This involves applying the current contents of r, which is x (ref !x ), to the unit value (). This results in an attempt to evaluate !(), i.e. to dereference something which is not a storage location, an unsafe operation which should be trapped. Put more formally, we have M, { } FAIL in the transition system dened in Figure 4 and Slide 34 (using the rather terse evaluation contexts style of Wright and Felleisen (1994)). The congurations of the transition system are of two kinds: A pair M, s , where M is an ML expression and s is a statea nite function mapping variables, x, (here being used as the names of storage locations) to syntactic values, V . (The possible forms of V for this fragment of ML are dened in Figure 4.) Furthermore, we require a well-formedness condition for such a pair to be a conguration: the free variables of M and of each value s(x) (as x ranges over dom(s)) should be contained in the nite set dom(s). The symbol FAIL, representing a run-time error. (The notation s[x V ] used on Slide 34 means the state with domain of denition dom(s) {x} mapping x to V and otherwise acting like s.)
Midi-ML transitions involving references
!x, s s(x), s
if x
dom(s)
!V, s FAIL if V not a variable x := V , s (), s[x V ] V := V , s FAIL if V not a variable ref V, s x, s[x V ]
where V ranges over values: if x
dom(s) /
V ::= x | x(M ) | () | true | false | nil | V :: V
Slide 34
3.1 The problem
35
The axioms and rules inductively dening the transition system for Midi-ML are those on Slide 34 together with the following ones: if true then M1 else M2 , s M1 , s if false then M1 else M2 , s M2 , s if V then M1 else M2 , s FAIL, if V {true, false} / (x(M ))V , s M [V /x], s V V , s FAIL, if V not a function abstraction let x = V in M, s M [V /x], s case nil of nil => M | x1 :: x2 => M , s M, s case V1 :: V2 of nil => M | x1 :: x2 => M , s M [V1 /x1 , V2 /x2 ], s case V of nil => M | x1 :: x2 => M , s FAIL, if V is neither nil nor a consvalue M, s M , s E[M ], s E[M ], s M, s FAIL E[M ], s FAIL
where V ranges over values: V ::= x | x(M ) | () | true | false | nil | V :: V E ranges over evaluation contexts: E ::= | if E then M else M | E M | V E | let x = E in M | E :: M | V :: E | case E of nil => M | x :: x => M | ref E | !E | E := M | V := E
and E[M ] denotes the Midi-ML expression that results from replacing all occurrences of by M in E. Figure 4: Transition system for Midi-ML
36
3 POLYMORPHIC REFERENCE TYPES
3.2 Restoring type soundness
The root of the problem described in the previous section lies in the fact that typing expressions like let r = ref M1 in M2 with the (let) rule allows the storage location (bound to) r to have a type scheme generalising the reference type of the type of M1 . Occurrences of r in M2 refer to the same, shared location and evaluation of M2 may cause assignments to this shared location which restrict the possible type of subsequent occurrences of r. But the typing rule allows all these occurrences of r to have any type which is a specialisation of , and this can lead to unsafe expressions being assigned types, as we have seen. We can avoid this problem by devising a type system that prevents generalisation of type variables occurring in the types of shared storage locations. A number of ways of doing this have been proposed in the literature: see (Wright 1995) for a survey of them. The one adopted in the original, 1990, denition of Standard ML (Milner, Tofte, and Harper 1990) was that proposed by Tofte (1990). It involves partitioning the set of type variables into two (countably innite) halves, the applicative type variables (ranged over by ) and the imperative type variables (ranged over by ). The rule (ref) is restricted by insisting that only involve imperative type variables; in other words the principal type scheme of x(ref x) becomes ( ref ), rather than ( ref ). Furthermore, and crucially, the (let) rule (Slide 19) is restricted by requiring that when the type scheme = A ( ) assigned to M1 is such that A contains imperative type variables, then M1 must be a value (and hence in particular its evaluation does not create any fresh storage locations). This solution has the advantage that in the new system the typeability of expressions not involving references is just the same as in the old system. However, it has the disadvantage that the type system makes distinctions between expressions which are behaviourly equivalent (i.e. which should be contextually equivalent). For example there are many list-processing functions that can be dened in the pure functional fragment of ML by recursive denitions, but which have more efcient denitions using local references. Unfortunately, if the type scheme of the former is something like ( list list), the type scheme of the latter may well be the different type scheme ( list list). So we will not be able to use the two versions of such a function interchangeably. The authors of the revised, 1996, denition of Standard ML (Milner, Tofte, Harper, and MacQueen 1997) adopt a simpler solution, proposed independently by Wright (1995). This removes the distinction between applicative and imperative type variables (in effect, all type variables are imperative, but the usual symbols , . . . are used) while retaining a valuerestricted form of the (let) rule, as shown on Slide 35.1 Thus our version of this type system is based upon exactly the same form of type, type scheme and typing judgement as before, with the typing relation being generated inductively by the axioms and rules on Slides 1619 and 32, except that the applicability of the (let) rule is restricted as on Slide 35.
N.B. what we call a value, (Milner, Tofte, Harper, and MacQueen 1997) calls a non-expansive expression.
1
3.2 Restoring type soundness
37
Value-restricted typing rule for let-expressions
M1 : 1 , x : A (1 ) M2 : 2
(letv)
let x = M1 in M2 : 2
()
() provided x dom() and / {} if M1 is not a value A= ftv (1 ) ftv () if M1 is a value
(Recall that values are given by
V ::= x | x(M ) | () | true | false | nil | V :: V .)
Slide 35
Example 3.2.1. The expression on Slide 33 is not typeable in the type system for Midi-ML resulting from replacing rule (let) by value-restricted the rule (letv) on Slide 35 (keeping all the other axioms and rules the same). Proof. Because of the form of the expression, the last rule used in any proof of its typeability must end with (letv). Because of the side condition on that rule and since ref x(x) is not a value, the rule has to be applied with A = { }. This entails trying to type (7) let u = (r := x (ref !x )) in (!r)()
in the typing environment = {r : ( ) ref }. But this is impossible, because the type variable is not universally quantied in this environment, whereas the two instances of r in (7) are of different implicit types (namely ( ref ref ) ref and (unit unit) ref ). The above example is all very well, but how do we know that we have achieved safety with this type system for Midi-ML? The answer lies in a formal proof of the type soundness property stated on Slide 36. To prove this result, one rst has to formulate a denition of typing for general congurations M, s when the state s is non-empty and then show typing is preserved under steps of transition, ; if a conguration can be typed, it cannot posses a transition to FAIL.
38
3 POLYMORPHIC REFERENCE TYPES
Thus a sequence of transitions from such a well-typed conguration can never lead to the F AIL conguration. We do not have the time to give the details in this course: the interested reader is referred to (Wright and Felleisen 1994; Harper 1994) for examples of similar type soundness results.
Type soundness for Midi-ML with the value restriction For any closed Midi-ML expression M , if there is some type scheme for which
M :
is provable in the value-restricted type system (axioms and rules on Slides 1618, 32 and 35), then evaluation of M does not fail, i.e. there is no sequence of transitions of the form
M, { } FAIL
for the transition system dened in Figure 4 (where { } denotes the empty state).
Slide 36
Although the typing rule (letv) does allow one to achieve type soundness for polymorphic references in a pleasingly straightforward way, it does mean that some expressions not involving references that are typeable in the original ML type system are no longer typeable (Exercise 3.3.2.) Wright (1995, Sections 3.2 and 3.3) analyses the consequences of this and presents evidence that it is not a hindrance to the use of Standard ML in practice.
3.3 Exercises
Exercise 3.3.1. Letting M denote the expression on Slide 33 and { } the empty state, show that M, { } FAIL is provable in the transition system dened in Figure 4. Exercise 3.3.2. Give an example of a Mini-ML let-expression which is typeable in the type system of Section 2.1, but not in the type system of Section 3.2 for Midi-ML with the value-restricted rule (letv).
4 Polymorphic Lambda Calculus
In this section we take a look at a type system for explicitly typed parametric polymorphism, variously called the polymorphic lambda calculus, the second order typed lambda calculus, or system F. It was invented by the logician Girard (1972) and, independently and for different purposes, by the computer scientist Reynolds (1974). It has turned out to play a foundational role in the development of type systems somewhat similar to that played by Churchs untyped lambda calculus in the development of functional programming. Although it is syntactically very simple, it turns out that a wide range of types and type constructions can be represented in the polymorphic lambda calculus.
4.1 From type schemes to polymorphic types
We have seen examples (Example 2.1.2 and the rst example on Slide 21) of the fact that the ML type system permits let-bound variables to be used polymorphically within the body of a let-expression. As Slide 37 points out, the same is not true of -bound variables within the body of a function abstraction. This is a consequence of the fact that ML types and type schemes are separate syntactic categories and the function type constructor, , operates on the former, but not on the latter. Recall that an important purpose of type systems is to provide safety (Slide 3) via type soundness (Slide 4). Use of expressions such as those mentioned on Slide 37 does not seem intrinsically unsafe (although use of the second one may cause nonterminationcf. the denition of the xed point combinator in untyped lambda calculus). So it is not unreasonable to seek type systems more powerful than the ML type system, in the sense that more expressions become typeable. One apparently attractive way of achieving this is just to merge types and type schemes together: this results in the so-called polymorphic types shown on Slide 38. So let us consider extending the ML type system to assign polymorphic types to expressions. So we consider judgements of the form M : where:
is a polymorphic type;
is a nite function from variables to polymorphic types.
In order to make full use of the mixing of and present in polymorphic types we have to replace the axiom (var ) of Slide 16 by the axiom and two rules shown on Slide 39. (These are in fact versions for polymorphic types of admissible rules in the original ML type system.) In rule (spec), [ /] indicates the polymorphic type resulting from substituting for all free occurrences of in . 39
40
4 POLYMORPHIC LAMBDA CALCULUS
-bound variables in ML cannot be used
polymorphically within a function abstraction
E.g. f ((f system.
true) :: (f nil)) and f (f f ) are not typeable in the ML type
Syntactically, because in rule
(fn)
, x : 1
M : 2
x(M ) : 1 2
the abstracted variable has to be assigned a trivial type scheme (recall
x : 1 stands for x : { } (1 )).
Semantically, because A (1 ) 2 is not semantically equivalent to an ML type when A
= { }.
Slide 37
Monomorphic types . . .
::= | bool | | list
. . . and type schemes
::= | ()
Polymorphic types
::= | bool | | list | ()
E.g. is a type, ( type scheme.
) is a type scheme and a polymorphic type (but not a monomorphic type), () is a polymorphic type, but not a
Slide 38
4.1 From type schemes to polymorphic types
41
Identity, Generalisation and Specialisation (id)
x : if (x : ) M : M : () M : () M : [ /]
if
(gen)
ftv () /
(spec)
Slide 39
Example 4.1.1. In the modied ML type system (with polymorphic types and (var ) replaced by (id), (gen), and (spec)) one can prove the following typings for expressions which are untypeable in ML: (8) (9) {} {} f ((f true) :: (f nil)) : ( ) bool list f (f f ) : () ().
Proof. The proof of (8) is rather easy to nd and is left as an exercise. Here is a proof for (9): f : 1 (1 ) f : 1 (1 ) f : 1 (1 ) f : 2 2 (id) (1) f : 1 (1 ) f : 1 (1 ) f : 2 (id) (2)
f : 1 (1 ) f f : 2 (gen)
f : 1 (1 ) f : 1 (1 ) {}
(app)
f f : 2 (2 )
f (f f ) : 1 (1 ) 2 (2 )
(fn).
Nodes (1) and (2) are both instances of the (spec) rule: the rst uses the substitution (2 2 )/1 , whilst the second uses 2 /1 .
42
4 POLYMORPHIC LAMBDA CALCULUS
Fact (see Wells 1994): For the modied ML type system with polymorphic types and (var typeability problems (cf. Slide 7) are equivalent and undecidable. ) replaced by the axiom and rules on Slide 39, the type checking and
Slide 40
So why does the ML programming language not use this extended type system with polymorphic types? The answer lies in the result stated on Slide 40: there is no algorithm to decide typeability for this type system (Wells 1994). The difculty with automatic type inference for this type system lies in the fact that the generalisation and specialisation rules are not syntax-directed: since an application of either (gen) or (spec) does not change the expression M being checked, it is hard to know when to try to apply them in the bottom-up construction of proof inference trees. By contrast, in an ML type system based on (id), (gen) and (spec), but retaining the two-level stratication of types into monomorphic types and type schemes, this difculty can be overcome. For in that case one can in fact push uses of (spec) right up to the leaves of a proof tree (where they merge with (id) axioms to become (var ) axioms) and push uses of (gen) right down to the root of the tree (and leave them implicit, as we did on Slide 19).
4.2 The PLC type system
The negative result on Slide 40 does not rule out the use of the polymorphic types of Slide 38 in programming languages, since one may consider explicitly typed languages (Slide 41) where the tagging of expressions with type information renders the typeability problem essentially trivial. We consider such a language in this subsection, the polymorphic lambda calculus (PLC).
4.2 The PLC type system
43
Explicitly versus implicitly typed languages Implicit: little or no type information is included in program phrases and typings have to be inferred (ideally, entirely at compile-time). (E.g. Standard ML.) Explicit: most, if not all, types for phrases are explicitly part of the syntax. (E.g. Java.)
E.g. self application function of type () () (cf. Example 4.1.1) Implicitly typed version: Explicitly type version:
f (f f )
f : 1 (1 ) ( 2 (f (2 2 )(f 2 )))
Slide 41
Remark 4.2.1 (Explicitly typed languages). One often hears the view that programming languages which enforce a large amount of explicit type information in programs are inconveniently verbose and/or force the programmer to make algorithmically irrelevant decisions about typings. But of course it really depends upon the intended applications. At one extreme, in a scripting language (interpreted interactively, used by a single person to develop utilities in a rapid edit-run-debug cycle) implicit typing may be desirable. Whereas at the opposite extreme, a language used to develop large software systems (involving separate compilation of modules by different teams of programmers) may benet greatly from explicit typing (not least as a form of documentation of programmers intentions, but also of course to enforce interfaces between separate program parts). Apart from these issues, explicitly typed languages are useful as intermediate languages in optimising compilers, since certain optimising transformations depend upon the type information they contain. See (Harper and Stone 1997), for example.
44
4 POLYMORPHIC LAMBDA CALCULUS
PLC syntax Types
::= type variable | function type | ( ) -type x x : (M ) MM (M ) M
variable function abstraction function application type generalisation type specialisation
Expressions
M
::= | | | |
( and x range over xed, countably innite sets TyVar and Var respectively.)
Slide 42
Functions on types In PLC,
(M ) is an anonymous notation for the function F mapping each type to the value of M [ /] (of some particular type). F denotes the result of applying such a function to a type.
Computation in PLC involves beta-reduction for such functions on types
( (M )) M [ /]
as well as the usual form of beta-reduction from -calculus
( x : (M1 )) M2 M1 [M2 /x]
Slide 43
4.2 The PLC type system
45
The explicit type information we need to add to expressions to get syntax-directed versions of the (gen) and (spec) rules (Slide 39) concerns the operations of type generalisation and type specialisation. These are forms of function abstraction and application respectivelyfor functions dened on the collection of all types (and taking values in one particular type), rather than on the values of one particular type. See Slide 43. The polymorphic lambda calculus, PLC, provides rather sparse means for dening such functionsfor example there is no typecase construct that allows branching according to which type expression is input. As a result, PLC is really a calculus of parametrically polymorphic functions (cf. Slide 8). The PLC syntax is given on Slide 42. Its types, , are like the polymorphic types, , given on Slide 38, except that we have omitted bool and ( ) listbecause in fact these and many other forms of datatype are representable in PLC (see Section 4.4 below). We have also omitted let-expressions, because (unlike the ML type system presented in Section 2.1) they are denable from function abstraction and application with the correct typing properties: see Exercise 4.5.3. Remark 4.2.2 (Operator association and scoping). As in the ordinary lambda calculus, one often writes a series of PLC applications without parentheses, using the convention that application associates to the left. Thus M1 M2 M3 means (M1 M2 )M3 , and M1 M2 3 means (M1 M2 )3 . Note that an expression like M1 2 M3 can only associate as (M1 2 )M3 , since association the other way involves an ill-formed expression (2 M3 ). Similarly M1 2 3 can only be associated as (M1 2 )3 (since 1 2 is an ill-formed type). On the other hand it is conventional to associate a series of function types to the right. Thus 1 2 3 means 1 (2 3 ). We delimit the scope of -, -, and -binders with parentheses. Another common way of writing these binders employs dot notation . x : . M . M
with the convention that the scope extends as far to the right as possible. For example 1 . (2 . 1 ) 1 means 1 ( 2 ( 1 ) 1 ). One often writes iterated binders using lists of bound (type) variables: 1 , 2 ( ) = 1 ( 2 ( )) x1 : 1 , x2 : 2 (M ) = x1 : 1 ( x2 : 2 (M )) 1 , 2 (M ) = 1 ( 2 (M )) . It is also common to write a type specialisation by subscripting the type: M = M . Remark 4.2.3 (Free and bound (type) variables). Any occurrences in of a type variable become bound in ( ). Thus by denition, the nite set, ftv ( ), of free type variables of a type , is given by ftv () = {} ftv (1 2 ) = ftv (1 ) ftv (2 ) ftv ( ( )) = ftv ( ) {}.
def def def def def def def
46
4 POLYMORPHIC LAMBDA CALCULUS
Any occurrences in M of a variable x become bound in x : (M ). Thus by denition, the nite set, fv (M ), of free variables of an expression M , is given by fv (x) = {x} fv ( x : (M )) = fv (M ) {x} fv (M1 M2 ) = fv (M1 ) fv (M2 ) fv ( (M )) = fv (M ) fv (M ) = fv (M ). Moreover, since types occur in expressions, we have to consider the free type variables of an expression. The only type variable binding construct at the level of expressions is generalisation: any occurrences in M of a type variable become bound in (M ). Thus ftv (x) = { } ftv ( x : (M )) = ftv ( ) ftv (M ) ftv (M1 M2 ) = ftv (M1 ) ftv (M2 ) ftv ( (M )) = ftv (M ) {} ftv (M ) = ftv (M ) ftv ( ). As usual, we implicitly identify PLC types and expressions up to alpha-conversion of bound type variables and bound variables. For example ( x : ( (x ))) x and ( x : ( (x ))) x
def def def def def def def def def def
are alpha-convertible. We will always choose names of bound variables as in the second expression rather than the rst, i.e. distinct from any free variables (and from each other). Remark 4.2.4 (Substitution). For PLC, there are three forms of (capture-avoiding) substitution, well-dened up to alpha-conversion: [ /] denotes the type resulting from substituting a type for all free occurrences of the type variable in a type . M [M /x] denotes the expression resulting from substituting an expression M for all free occurrences of the variable x in the expression M . M [ /] denotes the expression resulting from substituting a type for all free occurrences of the type variable in an expression M . The PLC type system uses typing judgements of the form shown on Slide 44. Its typing relation is the collection of such judgements inductively dened by the axiom and rules on Slide 45.
4.2 The PLC type system
47
PLC typing judgement takes the form
M : where
the typing environment is a nite function from variables to PLC
types. (We write
= {x1 : 1 , . . . , xn : n } to indicate that has domain of denition dom() = {x1 , . . . , xn } and maps each xi to the PLC type i for i = 1..n.)
M is a PLC expression is a PLC type.
Slide 44
PLC type system (var) (fn)
x : if (x : ) , x : 1 M : 2
if x
x : 1 (M ) : 1 2 M1 : 1 2 M1 M2 : 2 M :
if
dom() /
(app)
M2 : 1
(gen)
(M ) : ( ) M : (1 ) M 2 : 1 [2 /]
ftv () /
(spec)
Slide 45
48
4 POLYMORPHIC LAMBDA CALCULUS
An incorrect proof
x1 : , x2 : x1 : x1 :
x2 :
(var) (fn) (wrong!)
x2 : (x2 ) :
( x2 : (x2 )) : ( )
Slide 46
Remark 4.2.5 (Side-condition on rule (gen)). To illustrate the force of the side-condition on rule (gen) on Slide 45, consider the last step of the proof on Slide 46. It is not a correct instance of the (gen) rule, because the concluding judgement, whose typing environment = {x1 : }, does not satisfy ftv () (since ftv () = {} in this case). On the / other hand, the expression ( x2 : (x2 )) does have type ( ) given the typing environment {x1 : }. Here is a correct proof of that fact: x1 : , x2 : x1 : x1 : x2 : (var) (fn) (gen)
x2 : (x2 ) :
( x2 : (x2 )) : ( )
where we have used the freedom afforded by alpha-conversion to rename the bound type variable to make it distinct from the free type variables of the typing environment: since we identify types and expressions up to alpha-conversion, the judgement x1 : is the same as x1 : ( x2 : (x2 )) : ( ) ( x2 : (x2 )) : ( )
4.2 The PLC type system
and indeed, is the same as x1 : ( x2 : (x2 )) : ( ).
49
Example 4.2.6. On Slide 41 we claimed that f : 1 (1 ) ( 2 (f (2 2 )(f 2 ))) has type () (). Here is a proof of that in the PLC type system:
f : 1 (1 ) f : 1 (1 )
f : 1 (1 )
(var) (spec)
f : 1 (1 ) f : 1 (1 )
f : 1 (1 ) f 2 : 2 (gen)
(var) (spec)
f (2 2 ) : 2 2 f : 1 (1 )
f (2 2 )(f 2 ) : 2
(app)
f : 1 (1 ) {}
2 (f (2 2 )(f 2 )) : 2 (2 )
f : 1 (1 ) ( 2 (f (2 2 )(f 2 ))) : ( 1 (1 )) 2 (2 )
(fn).
Example 4.2.7. There is no PLC type for which (10) {} (( x : (x)) ) :
is provable within the PLC type system. Proof. Because of the syntax-directed nature of the axiom and rules of the PLC type system, any proof of (10) would have to look like
x: {} {} {}
x:
(var) (fn) (spec) (gen)
x : (x) : ( x : (x)) :
(( x : (x)) ) :
for some types , and . For the application of rule (fn) to be correct, it must be that = . But then the application of rule (spec) is impossible, because is not a -type. So no such proof can exist.
50
4 POLYMORPHIC LAMBDA CALCULUS
Decidability of the PLC typeability and type-checking problems Theorem. For each PLC typing problem,
M : ?, there is at most one PLC type for which M : is provable. Moreover there is an algorithm, typ , which when given any M : ? as input, returns such a if it exists and FAILs otherwise.
Corollary. The PLC type checking problem is decidable: we can decide whether or not
M : is provable by checking whether typ(
M : ?) = .
(N.B. equality of PLC types up to alpha-conversion is decidable.)
Slide 47
4.3 PLC type inference
As Examples 4.2.6 and 4.2.7 suggest, the type checking and typeability problems (Slide 7) are very easy to solve for the PLC type system, compared with the ML type system. This is because of the explicit type information contained in PLC expressions together with the syntax-directed nature of the typing rules. The situation is summarised on Slide 47. The uniqueness of types property stated on the slide is easy to prove by induction on the structure of the expression M , exploiting the syntax-directed nature of the axiom and rules of the PLC type system. Moreover, the type inference algorithm typ emerges naturally from this proof, dened recursively according to the structure of PLC expressions. The clauses of its denition are given on Slides 48 and 49.1 The denition relies upon the easily veried fact that equality of PLC types up to alpha-conversion is decidable. It also assumes that the various implicit choices of names of bound variables and bound type variables are made so as to keep them distinct from the relevant free variables and free type variables. For example, in the clause for type generalisations (M ), we assume the bound type variable is chosen so that ftv (). /
An implementation of this algorithm in Fresh OCaml (www.freshml.org/foc/) can be found on the course web page. The Fresh OCaml code is remarkably close to the informal pseudocode given here, because of Fresh OCamls sophisticated facilities for dealing with binding operations and fresh names.
1
4.3 PLC type inference
51
PLC type-checking algorithm, I Variables:
typ(, x :
x : ?) =
def
def
Function abstractions:
typ( x : 1 (M ) : ?) = let 2 = typ(, x : 1 M : ?) in 1 2
Function applications:
typ( M1 M2 : ?) = let 1 = typ( M1 : ?) in let 2 = typ( M2 : ?) in case 1 of if = 2 then else FAIL | FAIL
Slide 48
def
PLC type-checking algorithm, II Type generalisations:
typ( (M ) : ?) = let = typ( M : ?) in ( )
Type specialisations:
def
typ( M 2 : ?) = let = typ( M : ?) in case of (1 ) 1 [2 /] FAIL |
def
Slide 49
52
4 POLYMORPHIC LAMBDA CALCULUS
4.4 Datatypes in PLC
The aim of this subsection is to give some impression of just how expressive is the PLC type system. Many kinds of datatype, including both concrete data (booleans, natural numbers, lists, various kinds of tree, . . . ) and also abstract datatypes involving information hiding, can be represented in PLC. Such representations involve dening a suitable PLC type for the data, dening some PLC expressions for the various operations associated with the data, demonstrating that these expressions have both the correct typings and the expected computational behaviour. In order to deal with the last point, we rst have to consider some operational semantics for PLC. Most studies of the computational properties of polymorphic lambda calculus have been based on the PLC analogue of the notion of beta-reduction from untyped lambda calculus. This is dened on Slide 50.
Beta-reduction of PLC expressions
M beta-reduces to M in one step, M M , means M can be obtained from M (up to alpha-conversion, of course) by
replacing a subexpression which is a redex by its corresponding reduct. The redex-reduct pairs are of two forms:
( x : (M1 )) M2 M1 [M2 /x] ( (M )) M [ /]. M M indicates a chain of nitely many beta-reductions.
( possibly zerowhich just means M and M are alpha-convertible).
M is in beta-normal form if it contains no redexes.
Slide 50
Example 4.4.1. Here are some examples of beta-reductions. The various redexes are shown
4.4 Datatypes in PLC
boxed. Clearly, the nal expression y is in beta-normal form. ( x : 1 1 (x y)) ( 2 ( z : 2 (z)))(1 1 )
53
( 2 ( z : 2 (z)))(1 1 ) y
( x : 1 1 (x y)) ( z : 1 1 (z))
( z : 1 1 (z))y
y
Properties of PLC beta-reduction on typeable expressions Suppose
M : is provable in the PLC type system. Then the M , then M : is also a provable
following properties hold: Subject Reduction. If M typing. Church Rosser Property. If M
M1 and M M2 , then there is M with M1 M and M2 M .
Strong Normalisation Property. There is no innite chain
M M1 M2 . . . of beta-reductions starting from M .
Slide 51
Slide 51 lists some important properties of typeable PLC expressions that we state without proof. The rst is a weak form of type soundness result (Slide 4) and its proof is straightforward. The proof of the Church Rosser property is also quite easy whereas the proof of Strong Normalisations is difcult.1 It was rst proved by (Girard 1972) using a
Since it in fact implies the consistency of second order arithmetic, it furnishes a concrete example of G dels famous incompleteness theorem: the strong normalisation property of PLC is a statement o
1
54
4 POLYMORPHIC LAMBDA CALCULUS
clever technique called reducibility candidates; if you are interested in seeing the details, look at (Girard 1989, Chapter 14) for an accessible account of the proof.
PLC beta-conversion, = By denition,
M = M holds if there is a nite chain M M
where each is either or , i.e. a beta-reduction in one direction or the other. (A chain of length zero is allowedin which case M and M are equal, up to alpha-conversion, of course.) Church Rosser + Strong Normalisation properties imply that, for typeable PLC expressions, M
= M holds if and only if there is some M N M
beta-normal form N with
Slide 52
Theorem 4.4.2. The properties listed on Slide 51 have the following consequences. (i) Each typeable PLC expression, M , possesses a beta-normal form, i.e. an N such that M N , which is unique (up to alpha-conversion). (ii) The equivalence relation of beta-conversion (Slide 52) between typeable PLC expressions is decidable, i.e. there is an algorithm which, when given two typeable PLC expressions, decides whether or not they are beta-convertible. Proof. For (i), rst note that such a beta-normal form exists because if we start reducing redexes in M (in any order) the chain of reductions cannot be innite (by Strong Normalisation) and hence terminates in a beta-normal form. Uniqueness of the beta-normal form follows by the Church Rosser property: if M N1 and M N2 , then N1 M N2 holds for some M ; so if N1 and N2 are beta-normal forms, then it must be that N1 M and N2 M are chains of beta-reductions of zero length and hence N1 = M = N2 (equality up to alpha-conversion). For (ii), we can use an algorithm which reduces the beta-redexes of each expression in any order until beta-normal forms are reached (in nitely many steps, by Strong Normalisation); these normal forms are equal (up to alpha-conversion) if and only if the original expressions are beta-convertible. (And of course, the relation of alpha-convertibility is decidable.)
that can be formalised within second order arithmetic, is true (as witnessed by a proof that goes outside second order arithmetic), but cannot be proved within that system.
4.4 Datatypes in PLC
55
Remark 4.4.3. In fact, the Church Rosser property holds for all PLC expressions, whether or not they are typeable. However, the Strong Normalisation properties denitely fails for untypeable expressions. For example, consider = ( f : (f f ))( f : (f f )) from which there is an innite chain of beta-reductions, namely . As with the untyped lambda calculus, one can regard polymorphic lambda calculus as a rather pure kind of typed functional programming language in which computation consists of reducing typeable expressions to beta-normal form. From this viewpoint, the properties on Slide 51 tell us that (unlike the case of untyped lambda calculus) PLC cannot be Turing powerful, i.e. not all partial recursive functions can be programmed in it (using a suitable encoding of numbers). This is simply because, by virtue of Strong Normalisation, computation always terminates on well-typed programs. Now that we have explained PLC dynamics, we return to the question of representing datatypes as PLC types. We consider rst the simple example of booleans and then the more complicated example of polymorphic lists.
def
Polymorphic booleans
bool = ( ( )) True = ( x1 : , x2 : (x1 )) False = ( x1 : , x2 : (x2 )) if = ( b : bool , x1 : , x2 : (b x1 x2 ))
def def def
def
Slide 53
Example 4.4.4 (Booleans). The PLC type corresponding to the ML datatype datatype bool = True | False
56
4 POLYMORPHIC LAMBDA CALCULUS
is shown on Slide 53. The idea behind this representation is that the algorithmic essence of a boolean, b, is the operation x1 : , x2 : (if b then x1 else x2 ) of type ,1 taking a pair of expressions of the same type and returning one or other of them. Clearly, this operation is parametrically polymorphic in the type , so in PLC we can take the step of identifying booleans with expressions of the corresponding -type, ( ). Note that for the PLC expressions True and False dened on Slide 53 the typings {} True : ( ) and {} False : ( )
are both provable. The if then else construct, given for the above ML datatype by a caseexpression case M1 of True => M2 | False => M3 has an explicitly typed analogue in PLC, viz. if M1 M2 M3 , where is supposed to be the common type of M2 and M3 and if is the PLC expression given on Slide 53. It is not hard to see that {} if : (bool ( ( ))).
Thus if M1 : bool , M2 : and M3 : , then if M1 M2 M3 : (cf. the typing rule (if) on Slide 16). Furthermore, the expressions True, False, and if have the expected dynamic behaviour:
if M1 True and M2 N , then if M1 M2 M3 N ; if M1 False and M3 N , then if M1 M2 M3 N .
It is in fact the case that True and False are the only closed beta-normal forms in PLC of type bool (up to alpha-conversion, of course), but it is beyond the scope of this course to prove it.
1
Recall our notational conventions: means ( ).
4.4 Datatypes in PLC
57
Polymorphic lists
list = ( ( ) ) Nil = , ( x : , f : (x )) Cons = (x : , : list( ( x : , f : ( f x ( x f )))))
def def
def
Slide 54
Iteratively dened functions on nite lists
A = nite lists of elements of the set A
Given a set A , an element x
def
A , and a function f : A A A , the iteratively dened function listIter x f is the unique function g : A A satisfying: g Nil = x g (x :: ) = f x (g ).
for all x
A and A .
Slide 55
58
4 POLYMORPHIC LAMBDA CALCULUS
Example 4.4.5 (Lists). The polymorphic type corresponding to the ML datatype datatype list = Nil | Cons of ( list) is shown on Slide 54. Undoubtedly it looks rather mysterious at rst sight. The idea behind this representation has to do with the operation of iteration over a list shown on Slide 55. The existence of such functions listIter x f does in fact characterise the set A of nite lists over a set A uniquely up to bijection. We can take the operation (11) x : , f : (listIter x f ) (of type ( ) ) as the algorithmic essence of the list : list. Clearly this operation is parametrically polymorphic in and so we are led to the -type given on Slide 54 as the polymorphic type of lists represented via the iterator operations they determine. Note that from the perspective of this representation, the nil list is characterised as that list which when any listIter x f is applied to it yields x . This motivates the denition of the PLC expression Nil on Slide 54. Similarly for the constructor Cons for adding an element to the head of a list. It is not hard to prove the typings: {} {} Nil : ( list) Cons : ( list list).
As shown on Slide 56, an explicitly typed version of the operation of list iteration can be dened in PLC: iter x f satises the dening equations for an iteratively dened function (11) up to beta-conversion.
List iteration in PLC
iter = , (x : , f : ( : list ( x f )))
satises:
def
iter : , ( ( ) list )
iter x f (Nil ) = x iter x f (Cons x ) = f x (iter x f )
Slide 56
4.5 Exercises
59
ML datatype null = ; datatype unit = Unit; 1 2 datatype (1 , 2 )sum = Inl of 1 | Inr of 2 ; datatype nat = Zero | Succ of nat; datatype binTree = Leaf | Node of binTree binTree;
PLC null = () unit = ( ) 1 2 = ((1 2 ) ) (1 , 2 )sum = ((1 ) (2 ) ) nat = ( ( ) ) binTree = ( ( ) )
def def def def def def
Figure 5: Some more algebraic datatypes Booleans and lists are examples of algebraic datatypes, i.e. ones which can be specied (usually recursively) using products, sums and previously dened algebraic datatypes. Thus in Standard ML such a datatype (called alg, with constructors C1 , . . . , Cm ) might be declared by datatype (1 , . . . , n )alg = C1 of 1 | | Cm of m where the types 1 , . . . , m are built up from the type variables 1 , . . . , n and the type (1 , . . . , n )alg itself, just using products and previously dened algebraic datatype constructors, but not, for example, using function types. Figure 5 gives some other algebraic datatypes and their representations as polymorphic types. In fact all algebraic datatypes can be represented in PLC: see (Girard 1989, Sections 11.35) for more details.
4.5 Exercises
Exercise 4.5.1. Give a proof inference tree for (8) in Example 4.1.1. Show that 1 (1 2 (2 )) bool list is another possible polymorphic type for f ((f true) :: (f nil)). Exercise 4.5.2. Show that if M : and M : are both provable in the PLC type def system, then = (equality up to -conversion). [Hint: show that H = {(, M, ) | M : & ( M : = )} is closed under the axioms and rules on Slide 45.]
60
4 POLYMORPHIC LAMBDA CALCULUS
Exercise 4.5.3. In PLC, dening the expression let x = M1 : in M2 to be an abbreviation for ( x : (M2 )) M1 , show that the typing rule M1 : 1 , x : 1 M2 : 2 if x dom() /
(let x = M1 : 1 in M2 ) : 2
is admissiblein the sense that the conclusion is provable if the hypotheses are. Exercise 4.5.4. The erasure, erase(M ), of a PLC expression M is the expression of the untyped lambda calculus obtained by deleting all type information from M : erase(x) = x erase( x : (M )) = x (erase(M )) erase(M1 M2 ) = erase(M1 ) erase(M2 ) erase( (M )) = erase(M ) erase(M ) = erase(M ). (i) Find PLC expressions M1 and M2 satisfying erase(M1 ) = x (x) = erase(M2 ) such that M1 : ( ) and M2 : 1 (1 2 (1 )) are provable PLC typings. (ii) We saw in Example 4.2.6 that there is a closed PLC expression M of type () () satisfying erase(M ) = f (f f ). Find some other closed, typeable PLC expressions with this property. (iii) [For this part you will need to recall, from the CST Part IB Foundations of Functional Programming course, some pro...