Type Inference (Part I)

Most programming languages include the notion of a type system. This is because types help uncover logical errors. Although typechecking can be done either statically (at compile time) or dynamically (at run time), static typechecking has the advantage that if your program typechecks, you know that there will be no type violations on any run; if typechecking is done dynamically, the fact that one run produced no type errors generally provides no guarantees about what will happen on other runs.

There are two different approaches to static typechecking:

1. Static Typing: A language is said to be statically typed if the type of every expression in program can be determined at compile time.

2. Strong Typing: A language is said to use strong typing if the types of all expressions can be analyzed at compile time to see if they are mutually consistent (if so, there will be no runtime type errors); however, the actual types of some expressions may not be known until runtime.

Both static and strong typing require type inference: a technique that determines the type of every expression (possibly given declarations of the types for some variables and some user-defined functions). The goal of static typing is to assign a monotype (a single type) to each expression; in contrast, strong typing may assign some expressions a polytype (a type with type variables).

The language we'll use is a subset of ML that is basically an enriched version of lambda calculus. A program will be an expression as defined by the following grammar:

exp	→	ID
	|	literal	// int, bool, list, or pair
	|	λ ID . exp	// function definition
	|	exp (exp)	// function application
	|	if exp then exp else exp	// normal if-then-else
	|	let ID = exp in exp	// define a "macro" or a non-recursive fn
	|	let rec ID = exp in exp	// define a recursive fn

The primitive types are:

• int
• bool
• homogeneous list (all elements have the same type)
• pair (not necessarily homogeneous)

The primitive functions are:

• plus, iszero, succ, pred
• cons (restricted to lists, not arbitrary s-expressions), car, cdr, null
• pair (create a pair of objects - not necessarily of the same type)

We will assume that all functions are in curried form (i.e., take only one argument),we'll use functions instead of operators (e.g., "plus(1)(2)" instead of "1+2"), and we'll use square brackets for list literals (e.g., [1,2,3]).

The goal of polymorphic type inference is:

given: a program (represented by its abstract-syntax tree)

find the most general type for each expression (each AST node) that is consistent with the rest of the program.

A definition of "most general type" appears below.

The interesting part of polymorphic type inference is that types can include type variables. A type is defined as follows:

• Base types (e.g., int, boolean) are types.
• Type variables (denoted by lower-case Greek letters or by t1 t2 etc.) are types.
• If T1 and T2 are types, so are:

  T1 → T2	// function
  T1 x T2	// pair
  T1-list	// list of objects of type T1
  (T1)	// as usual, parens can be used for grouping

If a type contains a variable it is a polytype; otherwise it is a monotype.

Here are the types of some of our primitive functions:

function	type
succ	int → int
iszero	int → boolean
plus (uncurried form)	(int x int) → int
plus (curried form)	int → (int → int)
cons (uncurried form)	(α x α-list) → α-list
cons (curried form)	α → (α-list → α-list)
car	α-list → α
pair	α → (β → (α x β))

Intuitively, a type variable means "any type", although if one type variable occurs multiple times in a type, then they all have to refer to the same type. For example, since we've restricted our attention to homogeneous lists, cons is restricted to operate on an object of some type and a list of objects of that same type, rather than an arbitrary object and an arbitrary list. Therefore, the type of cons is α → (α-list → α-list). We impose no such restriction on pair; its arguments can have unrelated types.

Recall that our goal is to find the most general type for each expression in a program. We'll use "T1 ⊇ T2" (where T1 and T2 are types) to mean: T1 is at least as general as T2, and we'll use "T1 ⊃ T2" to mean T1 is strictly more general than T2. Here's how the ordering is defined:

The notation T1 ⇒ T2 means that we can re-write T1 to T2 by replacing all occurrences of some type variable α in T1 with some other type. For example:
(α → α) ⇒ (int → int)
and
(α → β) ⇒ (α → bool) ⇒ (int → bool)

By definition:

• (T1 ⊇ T2) iff (T1 ⇒* T2), and
• (T1 ⊃ T2) iff (T1 ⊇ T2) and not (T2 ⊇ T1)

So for example:

α ⊃ int
(α x β) ⊃ (α x α) ⊃ (bool x bool)

Let's start by looking at an example:

let rec length = λ L . if null(L) then 0 else succ (length (cdr (L))) in ...

What do we know about the types of the expressions in this (incomplete) program?

1. The type of null is: α-list → bool.
2. The type of 0 is: int.
3. The type of succ is: int → int.
4. The type of cdr is: α-list → α-list.
5. The type of the condition part of an if must be: bool.
6. The types of the then and else parts of an if must be the same (so that the whole expression has a well-defined type).

Point 1 tells us that the type of L must be: α-list. Point 3 tells us that the type of length (cdr L) must be: int, and that the type of succ (length (cdr L)) is: int. The type of null(L) (namely bool) is consistent with point 5. Since both branches of the if have type int, the type of the whole if is int, and thus the type of length is: α-list → int.

As a motivating example, assume that length is a primitive function with type α-list → int. Consider the following function application (recall that list literals are enclosed in square brackets):

plus(length([1,2,3])) (length([true, false]))

This expression should typecheck, and should be discovered to have type int. However, using the approach defined so far, this code will be rejected. Here's a partially annotated AST; what we'd get after typechecking the left subtree (the application of plus to the result of length([1,2,3])).

                
                              apply
                             /     \
                (int → int) /       \
                        apply        apply
                       /   |          |   \
                      /    | (int)    |    \
                 plus     apply    length   [true,false]
       int → (int → int)  /  \    
                         /    \      
                     length   [1,2,3]
         (α-list → int)      (int-list)
          ** α = int **

              type env                    equalities
             ----------                  -----------
          plus: int → (int → int)          α = int
          length: α-list → int

Note that typechecking length([1,2,3]) caused us to infer that α = int (since length, of type α-list→α is applied to an int-list). That means that length is actually of type int-list→int. This is clearly wrong (since length should be applicable to any kind of list), and when we try to typecheck the right subtree (the application of length to the list [true, false]), we're in trouble! The application of length to the list [true,false] will be rejected, since you can't apply a function of type int-list→int to an argument of type bool-list.

The solution is to use generic type variables for polymorphic functions. A generic type variable is one that appears inside a "forall" quantifier. For example, the type of length should be the generic type:

∀ α. α-list → int

instead of the non-generic (unquantified) type we were using, and the type of pair should be:

∀ α. ∀ β. α → (β → (α x β))

When a function's type involves a generic type variable, it means that the type variable can take on different values each time the function occurs in the AST.

What about user-defined functions? We certainly want to allow polymorphic user-defined functions (like length). However, we have to be careful. Consider the following expression, which defines an anonymous function whose argument, f, is also a function:

λ f. pair(f(3))(f(true))

If f is given a generic type "∀ α. α", then we would infer: t1→(t2 x t3) as the type of the whole expression. That may seem OK, but now consider:

(λf. pair(f(3))(f(true)))(succ)

This expression should not typecheck (because succ applied to true is an error). However, if f gets a generic type, then typechecking will succeed (will fail to find the type error); we will find that t1 = int→int, and that the whole expression has type (t2 x t3):

                                
                        apply  (t2 x t3) 
                       /     \
                      /       \
  ( t1 → (t2 x t3) ) λ      succ (int → int)
                       
                   ...

To prevent this, the ID in an expression of the form

λ ID . exp

let f = λa.a in pair(f(3))(f(true))

We might conclude that in general, for a let expression:

let ID = exp1 in exp2

1. Typecheck exp1, producing type T1.
2. Add the mapping (ID → T2) to the type environment, where T2 is T1 with "foralls" added to the front for every type variable in T1.
3. Typecheck exp2.

λg. let f = g in pair(f(3))(f(true))

So to typecheck a let expression we should do the three steps listed above except that we do not add a "forall" to the front of T1 for a type variable that is the type of an ID in some enclosing lambda.

What about recursive definitions; expressions of the form:

let rec f = exp1 in exp2

let f = Y( λf. exp1 ) in exp2