Fall 2001, CSE 520: Lectures 8 and 9

The Type system of Curry (Cont'ed)

Example

Consider the lambda term \x.x. Does it have a type? The answer is yes, in fact we can prove that \x.x has type A -> A for any type variable A. The proof is the following:

    
   (var) ----------------  
          x : A |- x : A
   (abs) ------------------
          |- \x.x : A -> A

Some questions

There are various questions that one may ask at this point. Here we list some of them:

Does a term always has a type?
If a term has a type, is this type unique?
If the type is not unique, is there a sort of "most natuaral type" that one can choose?
We have seen how to use the system so to prove that a given term has a given type (type checking). Is it possible also to use the system to infer a type for a term (type inference)?
Given a type T, does it always exists a term which has type T?
What is the relation between types and reduction? Namely, is the type of a term preserved under reduction?

We will discuss these questions in the rest of these notes and in the notes of the following lectures.

Polimorphism

In the pure lambda calculus, if a term M has a type T, then it has infinitely many types. Essentially, all the types that we can obtain from T by replacing the type variables with type expressions, are also types of M.

Example

Consider again the lambda term \x.x. We can prove that \x.x has also type (B -> B) -> (B -> B) for any type variable B. In fact, by replacing A by B -> B in the proof above, we obtain the following:

    
      (var) --------------------------
             x : B -> B |- x : B -> B 
   (abs) --------------------------------
          |- \x.x : (B -> B) -> (B -> B)

In a sense, however, the previous type (A -> A) seems a "better type". In fact, the type (B -> B) -> (B -> B) can be seen as a particular case of A -> A, but not viceversa. In other words, A -> A is more general than (B -> B) -> (B -> B). We can indeed prove that A -> A is the most general (or principal) type of \x.x.
Principal type
A type A is a principal (or most general) type of M if every other type of M can be derived from A by instantiation.
Theorem If a lambda term has a type, then it has a principal type, unique modulo renaming.
We don't give a formal proof of this theorem, but we show how to construct the principal type. Let us start with the example of the term \x.x. Intuitively, any proof of a type statement for \x.x must have the following form:
(var) ---------------- A = B x : A |- x : B (abs) ---------------- C = A -> B |- \x.x : C
The equation C = A -> B indicates the condition under which (abs) is applicable, and the equation A = B indicates the condition under which (var) is applicable. Hence A = B , C = A -> B are the conditions under which the proof is valid. Any solution of these equations (i.e. any substitution which makes A and B identical, and C and A -> B identical), applied to the type in the conclusion (i.e. C), will derive a type for \x.x. Clearly, the most general type is obtained by taking the most general solution of the equations (see section on unification below). One form of the most general solution is the substitution theta = [A/B, A->A/C]. theta, applied to C, gives the type A -> A. (Alternatively we could have considered the substitution [B/A , B->B/C], that would have given the type B -> B, which is equivalent to A -> A modulo renaming.)
Constructing the principal type
To construct the principal type of a term M, try to build a proof for the statement |- M : A, with A generic. If the (generic) proof can be built, then collect all the conditions (equations). If these equations are solvable, consider their most general solution theta. We have that
the principal type of M is A theta.
If, on the contray, the generic proof cannot be built, or the equations are not solvable, then M is not typeable.
Examples

[True], i.e. \x\y.x, has principal type A -> B -> A.
[False], i.e. \x\y.y, has principal type A -> B -> B.
[1], i.e. \x\y.x y, has principal type (A -> B) -> A -> B.

Type checking and type inference
As we have seen in the above examples, the Curry system can be used in two ways:

To find a proof for |- M : A, where A is a given type. This process is called Type Checking.
To derive a (principal) type for M, by constructing a proof and imposing the conditions as explained above. This process is called Type Inference.

Applications: ML
The programming language ML has a static analyser that performs type inference (and derives the principal type) on the basis of the Curry's system. For instance, if we write the declaration
- val f = fn x => x;
(remember that fn x => E is the ML syntax for \x.E), the ML answer is:
val f = fn : 'a -> 'a
(where 'a represents a type variable), meaning that f is a function of type 'a -> 'a.
Lambda terms without a type
Not all lambda terms have a type; for instance, \x.x x hasn't any. In fact, if we try to construct a proof for typing a term containing x x, we end up with the condition that the type A of x (occurring as the argument) should be equal to a type of the form A -> B (type of a function which takes x as an argument). This is clearly impossible for any finite type expression. Remeber that we are considering the type expressions generated by the grammar at the beginning of these notes, and that the expressions (strings) generated by a grammar are always finite. For the same reason, also the fixpoint operator Y has no type.
Note that x x represents the application of a generic function x to itself. There are functions for which it makes sense to be applied to themselves (for instance the identity function), but this is not the case for all functions.
From a semantic point of view, note that if A -> B is to be interpreted as the set of functions from a set A to a set B, then there is no non-trivial set A which can be equal to the set A -> B, for cardinality reasons. In fact, if A has cardinality n, and B has cardinality m, then A -> B has cardinality mⁿ. In domain theory, where it is desirable that such equations have a solution, A -> B is assumed to represent not all functions from A to B, but only a particular class of them.
Empty and inhabited types
We have seen that there are lambda terms without a type. Analogously, there are type expressions which do not represent the type of any lambda term. We say that they are "empty types" or "types which are not inhabited". Examples of such types are:

Any type variable A
A -> B, for any distinct type variables A and B
A -> A -> B, for any distinct type variables A and B
Both the inhabited and the empty types are infinitely many. We will see in next lectures that there is a nice characterization of the inhabited types:
the inhabited types are exactly the formulas which are valid in the intuitionistic propositional logic
where -> is to be interpreted as logical implication.
First order unification
We have seen that a type inference might require solving a set of equations between type expressions. We make now more precise what we mean by "solution" and by "most general solution". We give the general definition for equations between first-order terms, of which type expressions represent a particular case.
Definition Given a set of variables Var, and a set of function symbols Fun (possibly including constant symbols) the first-order terms are defined by the following grammar:
Term ::= Var | Fun(Term,...,Term)

In the case of type expressions, we have only one binary function symbol (represented in infix notation): the arrow ->.
Definition A substitution theta is any mapping theta : Var -> Term.
A substitution theta will be denoted by listing explicitly the result of its application to every variable (usually we are interested only in finite substitutions, i.e. substitutions which affect only a finite number of variables). More precisely, a substitution theta such that theta(x₁) = t₁,..., theta(x_n) = t_n, will be denoted by [t₁/x₁,..., t_n/x_n].
The application of a substitution theta to a term t, denoted by t theta, is the term obtained from t by replacing symultaneously each variable x by theta(x).
The composition of two substitutions sigma and theta is the substitution sigma theta s.t. for every variable x, (sigma theta)(x) = (x sigma)theta.
Definition Given a set of equations on terms E = {t₁ = u₁, ... , t_n = u_n}, a substitution theta is a unifier (solution) for E iff for each i we have that t_itheta is identical to u_itheta. A substitution theta is the most general unifier of E if it is a unifier for E and, for any other unifier sigma, there exists sigma' s.t. sigma = theta sigma' (i.e. sigma can be obtained by instantiating theta).
Example Consider the set of equations
E = {A = B->C , B->C = C->B}
We have that

theta = [B->B/A , B/C] is a unifier of E.
theta' = [B->C/A , B/C] is not a unifier of E (the substitution must be applied simultaneously to all the equations).
sigma = [(D->D)->(D->D)/A , D->D/B , D->D/C] is also a unifier of E.
theta is more general than sigma in fact, sigma = theta [D->D/B].
We can actually show that theta is the most general unifier for E.
There are various algoriths to find the most general unifier for a set of first order equations; for instance, the algorithm of Martelli-Montanari (see [Apt_Pellegrini, Section 2]. Note that in this reference they use a reversed notation for subsitution: x/t insteand of t/x).
Proposition The algorithm of Martelli-Montanari always terminates and it gives a most general unifier if the set of equations is solvable, failure otherwise.
Corollary Given a set of first order equations E, it is decidable whether E is solvable or not, and, if it is solvable, then it has a most general unifier (which is unique modulo renaming).
Uses of unification in programming languages

ML uses:

First order unification for type inference at compile time (transparent to the user)
Pattern matching (a sort of one-way unification) for evaluating function calls, at run time

Prolog uses first order unification for evaluating goals, at run time. For efficiency reasons the occur-check is usually not implemented.
Lambda Prolog uses:

First order unification for type checking at compile time (transparent to the user)
Higher Order Unification (unification of Higher-Order terms modulo alpha, beta and eta conversion) for evaluating goals, at run time.
HO unification is a conservative extension of FO unification, in the sense that if we give to lambda Prolog a FO equation, then we get back the FO most general unifier. Those who are interested can find the algorithm for HO unification in [G. Huet, A Unification Algorithm for Typed lambda-Calculus, Theoretical Computer Science 1:27-57, 1973.]

Some notes about the problem of scope
Consider the term \xx.x. Is this a legal term? Yes: it represents the term \x(\x.x) or equivalently (by alpha renaming) \x(\y.y). So, \xx.x is alpha equivalent to \xy.y (the term [false]). When trying to build the type of \xx.x, however, you must be careful: you could write something like this:
------------------- E = B x:B, x:D |- x : E ------------------- C = D -> E x:B |- \x.x : C ------------------- A = B -> C |- \xx.x : A
which would make you conclude that the type of the \xx.x is B -> D -> B. This is wrong: The type of \xx.x (aka \xy.y) is B -> D -> D and it is different from B -> D -> B. The two types are not even one the instance of the other.
This error comes from the fact that there are two assumptions with the same variable x (x:B, x:D) in one of the assertion. This should never happen, because if you get to that point it means that you don't know anymore which variable (in the assumption) represents the variable with the same name in the body.
In general, you should use different names for all the bound variables, and this problem will never arise.
Another solution would be to modify the abstraction rule so to introduce a sort of rule of scoping. Maybe we will see this technique later in the course.