Inference: Simple Type Inference.

by G.Morrisett but strongly inspired by C. McBride's JFP 13(6) article.

Benjamin showed you how to write a type-checker for a little programming language. Here, we're going to develop a type-inference algorithm. The real purpose here is to talk about a particular style of Coq proof development due to Adam Chlipala where we try to build proofs that are robust to changes. Another purpose is to show you how dependent types can become a crucial tool for constructing the termination argument of a function. In particular, we will see that writing unification requires a much more delicate treatment than is naturally apparent.

Abstract Syntax

We'll represent type variables using natural numbers. This will give us an easy way to generate fresh type variables when we need them.

For this little language, types will only include type variables, arrow types, and [nat].

Our terms will have variables, numbers, lambdas, and applications. We'll use strings to represent program variables.

A context associates a variable to a type -- we'll use this to help define our declarative type-checker.

Now we can define our typing relation.

Equality for types -- we can convince Coq to generate the code for us.

A type context is just a list of type variables. We will use a tctxt to track which type variables are in scope, and thus when types are well-formed.

We'll now define a simplification tactic which takes care of some busywork that we would otherwise have to do in all of our proofs. I've broken this into a simple tactic s and a looping tactic mysimp which repeats s, does some simplification, and tries auto with arith. In general, I've chosen to break apart basic constructors such as /\, \/, and *, and to decompose comparisons such as tvar_eq_dec. I've also put in some tactics to simplify equalities on pairs, and equalities on options.

Membership in a type context.

Membership is decidable. Note that here we use the refine tactic to construct the skeleton of the function, leaving the proofs to be filled in. We then chain refine with an application of the mysimp tactic which takes care of discharging all of the predicates.

Well-formed types.

A predicate for checking whether a variable x occurs free in a type t.

Occurs is decidable. Once again, we take advantage of the refine tactic.

Substitute t1 for x in t2.

If t is well-formed with respect to D, and x is in D, then if we substitute a type u for x and u is well-formed with respect D - x, then we get a type that is well-formed with respect to D - x. In short, we eliminate the variable x.

A substitution maps a type variable to a type.

The support is simply the domain of the substitution.

Well-formed substitution -- prevents duplicates for type variables, and ensures that the types are well-formed as we move down the list.

Apply a substitution to a type

Remove a list of type variables from a type context

If s is a substitution and t a type that are well-formed with respect to t, then applying s to t yields a type well-formed with respec to D - support s.

Congruences for substitution

Unification

We would like to write a unification procedure that takes two types t1 and t2 and produces an (optional) substitution s such that when we apply s to t1 and t2, it equates them. We might try to write the following:
    Fixpoint unify (t1 t2:type) : option substitution =
      if eq_type t1 t2 then (Some nil)
      else match t1, t2 with
           | Tvar_t x, t2 => if occurs x t2 then None else Some [(x,t2)]
           | t1, Tvar_t x => if occurs x t1 then None else Some [(x,t1)]
           | Arrow_t t11 t12, Arrow_t t21 t22 =>
             match unify t11 t21 with
             | None => None
             | Some s1 => match unify (substs s1 t12) (substs s1 t22) with
                          | None => None
                          | Some s2 => Some (s1 ++ s2)
                          end
             end
           | _, _ => None
          end

Unfortunately, Coq will reject this because the recursive call to unify (substs s1 t12) (substs s1 t22) isn't structurally decreasing. Indeed, after substitution, t12 and t22 could be bigger than what we started with. So does this algorithm terminate? The answer is "yes", but depends crucially on the occurs check. The thing to note is that once we map a type variable x to a type t, then this eliminates the variable x, but only if x does not occur in t. Thus, to argue that unify terminates, informally, we need to show on each recursive call that either the type gets smaller, or else the number of type variables that can occur free in the types we are unifying has gotten smaller. Unfortunately, Coq doesn't make it easy to write functions that have this kind of termination argument. We're going to take advantage of the Wellfounded library which allows us to build recursive computations as long as we can show that the recursive calls respect some partial order that has no infinite descending chains. In our case, we will pick an order on pairs (D,t) where D is a list of type variables and t is a type. The order will compare pairs lexicographically, so that if the length of the list of variables is smaller, or if the length of the lists is the same but the type is shorter, then the relation holds.

A tpair is really just a tctxt*type, but the lexographic ordering provided by the library supports and expects a generalized dependent pair.

Lexographic ordering on tctxt*type pairs.

A proof that the ordering is well-founded: This takes advantage of the Wellfounded library which already has results for natural numbers, and lexicographical orderings.

One consequence of defining unification in terms of this well-founded ordering is that we need to make sure we are always manipulating well-formed types and substitutions with respect to a type context D, else we won't be able to argue that the number of type variables gets smaller when we do a substitution. So we begin by defining a notion of a well-formed subsitution, indexed by a type context D. This will be what unification ultimately returns to make sure we can keep the recursion going.

Glueing together two well-formed substitutions.

Facts about lengths of typing contexts needed to discharge verification conditions below.

This is a critical little lemma that connects the occurs check with well-formedness. It tells us that when x doesn't occur in t but t is well-formed with respect to D, then t is also well-formed with respect to D - x.

Lemmas about the height of types

This is a key lemma which shows that for well-formed substitutions s1 and s2, if s1 equates two types, then s1++s2 does as well. This means that we can always extend a substitution with additional constraints and we will continue to equate types.

If the type is smaller, then the pair is smaller

If the context is smaller, then the pair is smaller

This is an abbreviation that will help write unification.

The main unification loop body: The body is parameterized by a tpair, that is (D,t1) and a function unify that can be invoked on any tpair smaller than (D,t1) and returns a function which when given t2, and proofs that t1 and t2 are well-formed with respect to D, returns an optional well-formed substitution with respect to D.

We tie the knot for unify using Fix_F which demands an accessibility proof for our initial tp. But this is easy since we've already shown all tpairs are accessible.

Finally, we can define unify the way we really wanted to by currying the initial type pair.

Proving Unification Correct.

We've managed to write a terminating unify function that Coq accepts. Now we need an induction principle so that we can reason about it. We'll start by building a generic induction principle for tpairs, again simply using the Wellfounded library.

This is the statement of correctness for unify -- if we get a substitution back, then if we apply it to the two types, we get back the same type.

The main lemma -- showing that unify is correct. Notice that we factored out much of the reasoning to a helper tactic usimp. We could probably do a better job of writing this so that it's robust to change.

A slightly nicer version of the correctness result for unification.

Type-Inference in Two Pieces: Constraint Generation and Constraint Solving

Now we're going to build a type-checker that takes advantage of unification. Usually, the type-checker eagerly unifies types as it goes, but for our purposes, it will be a little easier (and cleaner) to break inference into two pieces: constraint generation, and constraint solving. Constraint generation is actually a quite straightforward process over the abstract syntax of an expression. But we need to be able to (a) track a set of equality constraints, and (b) be able to generate fresh type variables. To encapsulate this sort of state, we will write our type-checker using a combination of a state monad and the option monad. The state will allow us to generate fresh type variables, and to record a set of generated equational constraints which must be satisified in order for the term to type-check. The option will be used to track when a type-error occurs.

Our monad definition. An M A is a function which when given a state record, returns an optional state record and A value.

The return for the monad -- I think of this as lifting a pure value into an effectful computation.

The bind operation for the monad -- this is just sequential composition of two effectful computations.

Some handy notation for bind lets us duplicate Haskell-style "do-notation".

For our specific monad, we have a failure operation which just returns None.

To generate a fresh variable, we increment the counter and add the variable to our list of generated type variables.

This just adds a pair of types that are meant to be equated to our list of constraints.

This is a monad command that tries to look up the type of a variable in a context, failing if the variable isn't found.

Finally, we can generate the constraints with this nice little definition. Note that if we tried to eagerly unify the constraints, then we'd need to use a much more complicated definition to track the fact that the context and types are well-formed with respect to the list of generated type variables. This is possible, but quite a bit more verbose. In general, I find that in Coq, it's best to avoid dependent types if you can, and rely on "after-the-fact" proving. But as with unify, sometimes there's no avoiding it.

Generated Constraints are Well-Formed

Now we want to show that the constraints generated by gen_constraints are well-formed with respect to the list of type variables D that we accumulate in the state. This will allow us to call unify on all of the pairs of constraints we accumulated. Various lemmas about weakening well-formedness proofs. Note that Twelf, these niggling little lemmas aren't necessary.

This defines the notion of a well-formed variable context G with respect to a type variable context D.

And this defines the notion of a well-formed list of constraints with respect to a type variable context D.

To solve the constraints, we need to call unify. But unify demands that it be given well-formed types with respect to some typing context D in order to ensure termination. So this is a big lemma that establishes the well-formedness of the constraints generated by gen_constraints. It tells us that if we start with a well-formed context G with respect to the type context st_D (which is in the initial state), and start with well-formed constraints in the state, then gen_constraints will only extend st_D and the constraints in the state, and the constraints will continue to be well-formed, and the resulting type will be well-formed. We need all of these pieces to get the induction to go through.

This just runs across a list of well-formed constraints, unifies them, and returns a final substitution.

Finally, we can write the type-checker! Our type-checker first generates constraints, follwed by unifying the constraints, and finally applies the resulting substitution to the type computed by gen_constraints, returning that type.

Correctness of the Type Checker

gen_constraints only adds constraints.

Additional constraints don't change whether a unifier succeeds.

Lifting subsitution to contexts.

The declarative typing relation respects substitution.

Lemmas on substitution for (term) variable contexts

We can add in "later" bits of a substitution with no effect on a type.

Typing is ensured under any substitution that respects the constraints generated by gen_constraints. This is the key correctness lemma for the type-checker -- it tells us that if we generate a set of constraints, and if we find a substitution that unifies those constraints, then if we apply that substitution to the context and type, we get a valid typing for the term we started with.

Unifying a list of constraints results in a substitution that equates every pair in the constraints.

The type-checker is correct with respect to the hasType relation

Potential exercises:

1. Add new constructs to the types and the expressions of the language. For example, you could add Plus_e and Minus_e operations on Nat_t's, or booleans and an If_e-expression, or unit, etc. See what proofs break and try to generalize them so that they (a) cover the new cases, and (b) will hopefully cover more future cases. 2. Some of the lemmas towards the end are not appropriately "Adam-ized". Rewrite them so that they are. 3. We only established the soundness of the type-checker. Prove its completeness. In particular, you should show that unification finds a minimal substitution that satisfies the set of constraints.