Note

This is an alternate version of Norm.v that is used as an example in Extraction2.v. It is not intended to be read on its own.

Normalization

(This chapter is optional.) In this chapter, we consider another fundamental theoretical property of the simply typed lambda-calculus: the fact that the evaluation of a well-typed program is guaranteed to halt in a finite number of steps—-i.e., every well-typed term is normalizable. Unlike the type-safety properties we have considered so far, the normalization property does not extend to full-blown programming languages, because these languages nearly always extend the simply typed lambda-calculus with constructs, such as general recursion (as we discussed in the MoreStlc chapter) or recursive types, that can be used to write nonterminating programs. However, the issue of normalization reappears at the level of types when we consider the metatheory of polymorphic versions of the lambda calculus such as F_omega: in this system, the language of types effectively contains a copy of the simply typed lambda-calculus, and the termination of the typechecking algorithm will hinge on the fact that a ``normalization'' operation on type expressions is guaranteed to terminate. Another reason for studying normalization proofs is that they are some of the most beautiful—-and mind-blowing—-mathematics to be found in the type theory literature, often (as here) involving the fundamental proof technique of logical relations. The calculus we shall consider here is the simply typed lambda-calculus over a single base type bool and with pairs. We'll give full details of the development for the basic lambda-calculus terms treating bool as an uninterpreted base type, and leave the extension to the boolean operators and pairs to the reader. Even for the base calculus, normalization is not entirely trivial to prove, since each reduction of a term can duplicate redexes in subterms.

Exercise: 1 star

Where do we fail if we attempt to prove normalization by a straightforward induction on the size of a well-typed term?

☐

Language

We begin by repeating the relevant language definition, which is similar to those in the MoreStlc chapter, and supporting results including type preservation and step determinism. (We won't need progress.) You may just wish to skip down to the Normalization section...

Syntax and Operational Semantics

Substitution

Reduction

Typing

Context Invariance

Preservation

☐

Determinism

Normalization

Now for the actual normalization proof. Our goal is to prove that every well-typed term evaluates to a normal form. In fact, it turns out to be convenient to prove something slightly stronger, namely that every well-typed term evaluates to a value. This follows from the weaker property anyway via the Progress lemma (why?) but otherwise we don't need Progress, and we didn't bother re-proving it above. Here's the key definition:

A trivial fact:

The key issue in the normalization proof (as in many proofs by induction) is finding a strong enough induction hypothesis. To this end, we begin by defining, for each type T, a set R_T of closed terms of type T. We will specify these sets using a relation R and write R T t when t is in R_T. (The sets R_T are sometimes called saturated sets or reducibility candidates.) Here is the definition of R for the base language:

• R bool t iff t is a closed term of type bool and t halts in a value
• R (T1 → T2) t iff t is a closed term of type T1 → T2 and t halts in a value and for any term s such that R T1 s, we have R T2 (t s).

This definition gives us the strengthened induction hypothesis that we need. Our primary goal is to show that all programs —-i.e., all closed terms of base type—-halt. But closed terms of base type can contain subterms of functional type, so we need to know something about these as well. Moreover, it is not enough to know that these subterms halt, because the application of a normalized function to a normalized argument involves a substitution, which may enable more evaluation steps. So we need a stronger condition for terms of functional type: not only should they halt themselves, but, when applied to halting arguments, they should yield halting results. The form of R is characteristic of the logical relations proof technique. (Since we are just dealing with unary relations here, we could perhaps more properly say logical predicates.) If we want to prove some property P of all closed terms of type A, we proceed by proving, by induction on types, that all terms of type A possess property P, all terms of type A→A preserve property P, all terms of type (A→A)->(A→A) preserve the property of preserving property P, and so on. We do this by defining a family of predicates, indexed by types. For the base type A, the predicate is just P. For functional types, it says that the function should map values satisfying the predicate at the input type to values satisfying the predicate at the output type. When we come to formalize the definition of R in Coq, we hit a problem. The most obvious formulation would be as a parameterized Inductive proposition like this: Unfortunately, Coq rejects this definition because it violates the strict positivity requirement for inductive definitions, which says that the type being defined must not occur to the left of an arrow in the type of a constructor argument. Here, it is the third argument to R_arrow, namely (∀ s, R T1 s → R TS (tapp t s)), and specifically the R T1 s part, that violates this rule. (The outermost arrows separating the constructor arguments don't count when applying this rule; otherwise we could never have genuinely inductive predicates at all!) The reason for the rule is that types defined with non-positive recursion can be used to build non-terminating functions, which as we know would be a disaster for Coq's logical soundness. Even though the relation we want in this case might be perfectly innocent, Coq still rejects it because it fails the positivity test. Fortunately, it turns out that we can define R using a Fixpoint:

As immediate consequences of this definition, we have that every element of every set R_T halts in a value and is closed with type t :

Now we proceed to show the main result, which is that every well-typed term of type T is an element of R_T. Together with R_halts, that will show that every well-typed term halts in a value.

Membership in R_T is invariant under evaluation

We start with a preliminary lemma that shows a kind of strong preservation property, namely that membership in R_T is invariant under evaluation. We will need this property in both directions, i.e. both to show that a term in R_T stays in R_T when it takes a forward step, and to show that any term that ends up in R_T after a step must have been in R_T to begin with. First of all, an easy preliminary lemma. Note that in the forward direction the proof depends on the fact that our language is determinstic. This lemma might still be true for non-deterministic languages, but the proof would be harder!

Now the main lemma, which comes in two parts, one for each direction. Each proceeds by induction on the structure of the type T. In fact, this is where we make fundamental use of the finiteness of types. One requirement for staying in R_T is to stay in type T. In the forward direction, we get this from ordinary type Preservation.

The generalization to multiple steps is trivial:

In the reverse direction, we must add the fact that t has type T before stepping as an additional hypothesis.

Closed instances of terms of type T belong to R_T

Now we proceed to show that every term of type T belongs to R_T. Here, the induction will be on typing derivations (it would be surprising to see a proof about well-typed terms that did not somewhere involve induction on typing derivations!). The only technical difficulty here is in dealing with the abstraction case. Since we are arguing by induction, the demonstration that a term tabs x T1 t2 belongs to R_(T1→T2) should involve applying the induction hypothesis to show that t2 belongs to R_(T2). But R_(T2) is defined to be a set of closed terms, while t2 may contain x free, so this does not make sense. This problem is resolved by using a standard trick to suitably generalize the induction hypothesis: instead of proving a statement involving a closed term, we generalize it to cover all closed instances of an open term t. Informally, the statement of the lemma will look like this: If x1:T1,..xn:Tn ⊢ t : T and v1,...,vn are values such that R T1 v1, R T2 v2, ..., R Tn vn, then R T ([x1:=v1][x2:=v2]...[xn:=vn]t). The proof will proceed by induction on the typing derivation x1:T1,..xn:Tn ⊢ t : T; the most interesting case will be the one for abstraction.

Multisubstitutions, multi-extensions, and instantiations

However, before we can proceed to formalize the statement and proof of the lemma, we'll need to build some (rather tedious) machinery to deal with the fact that we are performing multiple substitutions on term t and multiple extensions of the typing context. In particular, we must be precise about the order in which the substitutions occur and how they act on each other. Often these details are simply elided in informal paper proofs, but of course Coq won't let us do that. Since here we are substituting closed terms, we don't need to worry about how one substitution might affect the term put in place by another. But we still do need to worry about the order of substitutions, because it is quite possible for the same identifier to appear multiple times among the x1,...xn with different associated vi and Ti. To make everything precise, we will assume that environments are extended from left to right, and multiple substitutions are performed from right to left. To see that this is consistent, suppose we have an environment written as ...,y:bool,...,y:nat,... and a corresponding term substitution written as ...[y:=(tbool true)]...[y:=(tnat 3)]...t. Since environments are extended from left to right, the binding y:nat hides the binding y:bool; since substitutions are performed right to left, we do the substitution y:=(tnat 3) first, so that the substitution y:=(tbool true) has no effect. Substitution thus correctly preserves the type of the term. With these points in mind, the following definitions should make sense. A multisubstitution is the result of applying a list of substitutions, which we call an environment.

We need similar machinery to talk about repeated extension of a typing context using a list of (identifier, type) pairs, which we call a type assignment.

We will need some simple operations that work uniformly on environments and type assigments

An instantiation combines a type assignment and a value environment with the same domains, where corresponding elements are in R

We now proceed to prove various properties of these definitions.

More Substitution Facts

First we need some additional lemmas on (ordinary) substitution.

Properties of multi-substitutions

Closed environments are those that contain only closed terms.

Next come a series of lemmas charcterizing how msubst of closed terms distributes over subst and over each term form

You'll need similar functions for the other term constructors.

Properties of multi-extensions

We need to connect the behavior of type assignments with that of their corresponding contexts.

Properties of Instantiations

These are strightforward.

Congruence lemmas on multistep

We'll need just a few of these; add them as the demand arises.

The R Lemma.

We finally put everything together. The key lemma about preservation of typing under substitution can be lifted to multi-substitutions:

And at long last, the main lemma.

Normalization Theorem

MoreStlc: A Typechecker for STLC

The has_type relation of the STLC defines what it means for a term to belong to a type (in some context). But it doesn't, by itself, tell us how to check whether or not a term is well typed. Fortunately, the rules defining has_type are syntax directed — they exactly follow the shape of the term. This makes it straightforward to translate the typing rules into clauses of a typechecking function that takes a term and a context and either returns the term's type or else signals that the term is not typable.

Comparing Types

First, we need a function to compare two types for equality...

... and we need to establish the usual two-way connection between the boolean result returned by beq_ty and the logical proposition that its inputs are equal.

The Typechecker

Now here's the typechecker. It works by walking over the structure of the given term, returning either Some T or None. Each time we make a recursive call to find out the types of the subterms, we need to pattern-match on the results to make sure that they are not None. Also, in the tapp case, we use pattern matching to extract the left- and right-hand sides of the function's arrow type (and fail if the type of the function is not TArrow T11 T12 for some T1 and T2).

Properties

To verify that this typechecking algorithm is the correct one, we show that it is sound and complete for the original has_type relation — that is, type_check and has_type define the same partial function.