CSE 428: Lecture 24

The Type system of Mini ML (continued)

Constructing an expression with a given type

We have seen how to derive the type of a given expression. By reversing the reasoning, we can do the opposite, namely, given a type, we can derive an expression with that type.

Example

Consider the type

      alpha -> (alpha -> beta) -> beta

Let us try to construct an expression with this type. Clearly, it must be a (curried) function with two arguments, i.e. must have the following structure.

      fn ... => fn ... => ...

Let us now fill in the dots. Let us call x and f, respectively, the first and second argument of the function. Clearly x: alpha and f: alpha -> beta. Now we have only to construct an expression with type beta, and use it as result.

Let us use an analogy: think of alpha as milk, and of beta as yogurt. Then f represents a machine that transforms milk into yogurt. Now, we have some milk (x), we have the machine, and we want to obtain yougurt. What shall we do? The answer is, of course,

turn on the machine and put the milk in it

i.e. use f with input x. Hence, the resulting expression is:

      fn x => fn f => f x

Example

Consider the type

      (alpha * beta -> gamma) -> alpha -> beta -> gamma

An expression with this type must have the following structure:

      fn f => fn x => fn y => ...

where f: alpha * beta -> gamma, x: alpha, and x: beta. In order to fill in the result, let us use again an analogy similar to the above.

Look at f as a machine that, when provided with flour (alpha) and yeast (beta) together, it makes bread (gamma). We have some flour (x), we have some yeast (y), how to obtain bread? The answer is, of course,

use f and give it in input x and y together.

Hence the solution is:

      fn f => fn x => fn y => f(x,y)

Expressions without type

Not all expressions have a type.

Example

One of the simplest cases is the expression

      fn f => f f

Let us see why it does not have a type. If it did, it should be something like

      (alpha -> beta) -> beta

where f: alpha -> beta and (f f): beta. However, since f is also the argument in (f f), we should have f: alpha. But the equation alpha = alpha -> beta is unsatisfiable (at least for finite types, as it is the case in the Type Theory of ML. Such equation admits only an infinite solution alpha = ((...) -> beta) -> beta) -> beta.)

For a more intuitive explanation: Think again of f as a machine that transforms milk into yogurt. We can clone (make a copy) of this machine and try to feed the first machine with the second, but it won't work.

Example

Another example of an expression without type is

      fn f => fn x => (f x, f(x,x))

Intuitively, the type of f should be compatible with both the inputs x and (x,x). Namely, we should have at the same time f: alpha -> beta and f: alpha * alpha -> gamma. This would be possible only if the equation alpha = alpha * alpha were solvable, but this is not the case for finite types (a set cannot be equal to the cartesian product of the same set with itself). Note the analogy with the numeric equation x = x + 1, which is unsolvable (for finite numbers) for the same reason.

Note that if we write in ML the above expressions, we get a type error.

Types which do not correspond to any expression

There are also types which are not the type of any expression. They are called "empty types" or "types which are not inhabited". Examples of such types are:

      (alpha -> beta) -> beta
      (alpha -> beta) -> alpha
      beta -> (alpha -> beta) -> alpha
      alpha -> alpha * beta

If we try to construct an expression for any of these types, we won't succeed. Consider for instance the first type. We have a machine that tranforms milk into yogurt, but we don't have any milk. How can we obtain yogurt? The answer is "We can't". (Feeding the machine with (a copy of) itself does not work, as seen before. Selling the machine and using the money to buy yogurt is not allowed :-)

A criterion for empty types

There is an extremely interesting analogy between type theory and logics, which is known under the name of "Curry-Howard isomorphism". Basically the idea is that we can consider types as logical formulas. (Types here are meant as restricted to the types we can construct with -> and *.) More precisely:

-> corresponds to implication
* corresponds to conjunction
Type variables correspond to propositions

An important result is the following:

Theorem
A type is inhabited (i.e. not empty) only if it corresponds to a logically valid formula (i.e. a tautology).

For instance, the type (alpha -> beta) -> beta above is not a tautology and in fact it is empty. The type alpha -> (alpha -> beta) -> beta, on the contrary, is inhabited, and in fact it is a tautology.

Hence we can give the following criterion for the emptyness of a type t:

if t is not a tautology, then we know that t is empty

The reverse does not hold: there are types which are tautologies, but still are empty. One example of such a type is

      ((alpha -> alpha) -> alpha) -> alpha

In the sub-theory of Classical Logic called Intuitionistic Logic, however, the correspondence is complete. We have in fact that:

A type is inhabited (i.e. not empty) if and only if it corresponds to a formula intuitionistically valid.

Sub-theory here means that less formulae are valid.

Most general type

Consider an expression like

      fn x => x

The type of this expression is

      alpha -> alpha

Let us call f the function represented by the above expression. Clearly, we can use f also with less general (i.e. more instantiated) types, like for instance pairs, or functions. This means that f can be regarded also as a function of the follwing types:

      beta * gamma  -> beta * gamma
      (beta -> gamma)  -> beta ->gamma
      beta list  -> beta list
      ...

The difference between alpha -> alpha and the types above is that alpha -> alpha is more general: each type above can be obtained by replacing (instantiating) alpha with a more specific type (respectively, with beta * gamma, beta -> gamma and beta list). It is possible to prove that alpha -> alpha is the most general (or principal) type of the above expression. Any type for that expression can be obtained by intantiating the type alpha -> alpha.

Theorem
If an expression has a type, then it has a most general type.

This result is nice because it allows us to consider only the most general type t of an expression: if later, when we use the expression in a certain context, we need an other type, we know we can just derive it from t. The ML type system always derives the most general type of an expression.

How to compute the most general type

In all examples we have seen so far, the type we had constructed was the most general type. Let us see more formally how to do that.

In general, when we construct the type of an expression, we derive first the structure s of the type, and then, by analysing the expression, a set of equations E between type variables. The final type is then obtained by instantiating all the type variables in s so to reflect the constraints imposed by the equations.

More precisely, in order to make sure that we do not miss any constraint, and that we do not impose constraints that aren't necessary, we should instantiate s by using the "most general solution" of the set of equations E. A solution for E is an association between type variables and types which validates all the equations.

A solution for E can be expressed as a system of equations E' in solved form, i.e. such that the left hand sides of each equation is a distinct type variable, and the right hand sides are type expressions containing none of the variables of the lhs. We say that a solution E' for E is most general if E' is equivalent to E, i.e. E and E' have exactly the same solutions.

The most general solution for E can be obtained by repeatedly performing the following operations on E:

Simplify the equations. For instance, an equation

   alpha -> beta = gamma -> delta * epsilon

should be replaced by the two equations

   alpha = gamma 
   beta = delta * epsilon

Substitute the variables with their solution. For instance, if we have the equation
```
   alpha = gamma -> delta * epsilon
```
then we should replace alpha by gamma -> delta * epsilon in every other equations

If we succeed to transform E into a system in solved form, then we have found the most general solution (success). If we find an equation of the formalpha = ... alpha ...(i.e. the rhs contains alpha and something else), then we stop with failure, because we know that alpha = ... alpha ... is unsolvable unless the rhs is exactly alpha. It is possible to prove that we always stop, either with success or with failure.

Example

Consider the expression

      fn f => fn x => (f (f x))

Its type will have the following structure s:

      alpha -> beta -> gamma

With f: alpha, x: beta, and ((f (f x)): gamma. The constraints, which we derive from the form of the result ((f (f x)), are expressed by the following system of equations E:

 
      alpha = beta -> epsilon,  where (f x): epsilon, and
      alpha = epsilon -> gamma

The most general solution of this set of equations can be obtained by first replacing alpha by beta -> epsilon in the other equation:

 
      alpha = beta -> epsilon
      beta -> epsilon = epsilon -> gamma

then simplify the second equation:

 
      alpha = beta -> epsilon
      beta = epsilon 
      epsilon = gamma

then, replace epsilon by gamma (third equation) in the other equations:

 
      alpha = beta -> gamma
      beta = gamma
      epsilon = gamma

Finally, replace beta by gamma (second equation) in the other equations:

 
      alpha = gamma -> gamma
      beta = gamma
      epsilon = gamma

This final system is in solved form, hence it is the most general solution of E. By applying this solution to s we obtain the most general type, i.e.

      (gamma -> gamma) -> gamma -> gamma

Note that, when we solve a system of equations, there are in general several ways to proceed, depending on the choice of the particular equation considered at every step. Different choices bring to different (but equivalent) formulation of the result, and to different names in the final type. This does not matter, since the names of type variables are not important.

Declaration of functions: how to derive their type

Consider a definition of a function of the form

      fun f x = e

without recursion. In order to derive the type of f we can transform this declaration into the equivalent val declaration:

      val f = fn x => e

now we can derive the type of fn x => e in the way seen before. This will be also the type of f.

With a little bit of fantasy, we can apply the reasoning directly, without the need of transforming the fun declaration into a val declaration.

Functions defined by pattern matching

When we want to derive the type of a function defined by pattern matching, the reasoning is essentially the same as above. The only difference is that we may need to add some constraints coming from the patterns.

Example

Consider the following function f:

      fun f v [] = v
        | f v (x::l) = (x,x) :: []

f is curried and takes two arguments, hence the structure s of its type is

      alpha -> beta -> gamma

We have the following constraints:

 
      gamma = alpha,            from the result in the fst line
      beta = delta list,        from the pattern of the snd arg in the fst line
      gamma = (phi * phi) list, from the result in the snd line (where x: phi)
      delta = phi,              from the pattern of the snd arg in the snd line

A solved form of this system is

 
      beta = phi list,        
      gamma = (phi * phi) list,          
      alpha = (phi * phi) list, 
      delta = phi,

Which, applied to s, gives the type

      (phi * phi) list -> phi list -> (phi * phi) list

Recursive functions

Suppose that we want to derive the type of a function defined recursively. The reasoning is again the same as above, with the only difference that we need to add some constraints coming from the recursive calls.

Example

      fun f v [] = [v] 
        | f v (x::l) = f x l

f is curried and takes two arguments, hence the structure s of its type is

      alpha -> beta -> gamma

We have the following constraints:

 
      gamma = alpha list,       from the result in the fst line
      beta  = delta list,       from the pattern of the snd arg in the fst line
      delta = alpha,            from the recursive call in the snd line

A solution is

 
      gamma = alpha list
      beta  = alpha list
      delta = alpha

which, applied to s, gives the type

      alpha -> alpha list -> alpha list

The formal definition of the type system

For the sake of completeness, we give here the formal definition of the type system of Mini ML. This formal definition has not been given in class, and will not be required at the exam. However, it might help understanding better (and more precisely) the relation between expressions and types, which has been explained above at an intuitive level only.

The type system consists in a set of rules which define, inductively, the relation

      r |- e : t   (e has type t under the assumptions r)

where:

e is a Mini-ML expression
t is a Mini-ML type
r is a set of associations between type-variables and types

we will also use the notation r(x) to represent the type that is associated to x in r, and r[x:t] to represent the addition of the association x:t to r. This addition "shadows" a possible previous association for x in r.

Note the analogy of the type statement r |- e : t and the evaluation statement env |- e eval t in past lecture notes. Due to this analogy, the type system is sometimes called "static semantics", and r is called "static environment". The roles of r and env are very similar, and their behaviors define the same scoping rules.

Syntax of Mini-ML expressions and types

We recall here the definition of Mini ML and its types

    Exp ::= Ide                 (identifiers)
          | Exp Exp             (functional application)
          | fn Ide => Exp       (functional abstraction 1)
          | fn (Ide,Ide) => Exp (functional abstraction 2)
          | (Exp,Exp)           (pairing)
          | Exp :: Exp          (cons on lists)
          | hd Exp              (head of a list)
          | tl Exp              (tail of a list)
          | nil                 (empty list)

   Type ::= TVar             (type variables, i.e. parametres for types)
          | Type * Type      (Cartesian product, the type of pairs)
          | Type -> Type     (functional type, the type of functions)
          | Type list        (the type of lists)

Rules of the type system

Core of Mini ML (corresponding to the lambda calculus)

(ide)  ------------------  (where x is an identifier) 
         r |- x : r(x) 
  

         r |- e1 : alpha -> beta    r |- e2 : alpha 
(app)  ---------------------------------------------- 
                  r |- (e1 e2) : beta 

  
             r[x:alpha] |- e : beta 
(abs1) ---------------------------------- 
        r |- (fn x => e) : alpha -> beta

Pairs

              r[x:alpha][y:beta] |- e : gamma 
(abs2) ----------------------------------------------- 
        r |- fn (x,y) => e : (alpha * beta) -> gamma 
  
  
         r |- e1 : alpha    r |- e2 : beta 
(pair) --------------------------------------- 
                   r |- (e1,e2) : alpha * beta

Lists

         r |- e1 : alpha    r |- e2 : alpha list 
(cons) ------------------------------------------- 
              r |- (e1 :: e2) : alpha list 
  

         r |- e : alpha list 
(head) ----------------------- 
         r |- (hd e) : alpha
  

           r |- e : alpha list 
(tail) ---------------------------- 
         r |- (tl e) : alpha list


           
(nil) ---------------------------- 
         r |- nil : alpha list

A statement r |- e : t is derivable in the type system if there exists a proof tree for this statement.

We say that e has type t if we can derive the statement emptyset |- e : t.

In order to derive the most general type of an expression, we need to construct a proof for the statement emptyset |- e : alpha, and then instantiate alpha with the solution of the constraint that we find in this proof (i.e. the constraints imposed by the particular form of the types in the conclusion of the rules) from the var rule. A similar process allows us to derive an expression for a given type t.