Library stlc

This file models a very simple functional language known as the simply-typed lambda calculus (with nat's).

We only have two kinds of types: natural numbers and functions.

We will represent variables as strings -- later, we'll discuss alternative representations and the problems that arise when using simple first-order data structures to represent and reason about variables.

Expressions have only 4 forms: variables, constants, functions, and function calls.

When we evaluate a program, we get out a value. Values are a subset of the expressions and include just numbers and functions.

We'll model function call using substitution. Note that this is not a form of capture-avoiding substitution, so it assumes that the free variables of v do not conflict with the bound variables in e. Here, we're only going to consider substituting closed expressions (those with no free variables) so this won't be an issue.

A little notation for substitution.

We reserve some notation for use in the definition below. This will be our big-step semantics for expressions and is intended to mean that expression e evaluates to value v. Notice that here we are modeling call-by-name, whereas most languages use call-by-value. In particular, we don't evaluate the argument before substituting it for a formal parameter. In a call-by-value setting, we evaluate the argument before substitution. In a call-by-need setting (e.g., Haskell) we have to do something much more complicated.

Let us now define a small-step semantics for our language. We begin by defining the notion of a single step.

We then extend this to a reflexive, transitive closure of the single-step relation.

We can argue that the two semantics are equivalent.

Now we're going to consider a well-formedeness (typing) relation on terms. The basic idea is that we want to rule out "stuck" expressions where e.g., we have an unbound variable, or we pass an argument of the wrong type to a function, or we try to "apply" a number instead of a function.

We begin by defining contexts as lists of variables and types -- these are our assumptions. If you like, this is a kind of symbol table.

We use a last-in-first-out lookup to lookup a variable's type.

Our typing relation can be read: Under the assumptions in context G, expression e has type t. That is, when evaluated, e will not get stuck and will produce a value of type t.

Next, we want to prove that well-typed programs won't get stuck. Alternatively, we can argue that every well-typed program is already a (well-typed) value, or else it can take a step to a well-typed program. That's the positive way of saying it won't get stuck. Notice that we can't easily talk about this using the big-step semantics because it doesn't differentiate getting stuck from possible divergence. So we'll use the small-step semantics to argue this.

Our proof will break into two lemmas. One is a lemma that says well-formedness is preserved when taking a step. The other argues that if we're well-formed, then we are either a value or can take a step. Then soundness follows by induction on the number of steps we take.

progress follows as a corollary of the above.

Next, we need to define a substitution lemma, but to do so, we need a lot of auxiliary lemmas dealing with the context. Here's one group that I found good enough to push the result through.

Lookup on two contexts appended can be broken into two steps.

We can always add more assumptions to the right of a proof of has-type.

As a special case, when e has type t under the empty context, it continues to have type t under any context.

This lemma is used in the substitution case where we have a lambda that shadows the variable we are substituting for. In essence, it says we can drop the shadowed variable in the context and still construct a proof that the term e has type t.

Our substitution lemma has to be stated carefully to get the induction to go through, and so that we can use the auxiliary lemmas above to discharge all of the cases.

Once we have substitution, the rest of preservation is trivial.

And once we have progress and preservation, we can prove soundness.

Next, I'm going to show you a couple more ways to evaluate expressions in our simply typed lambda calculus. We'll begin with an environment- based semantics, where instead of substituting terms for variables, we carry around an environment, mapping variables to terms, as part of our evaluation. If you will, we're simultaneously substituting the environment while we're evaluating. Of course, we stop evaluating in some situations (e.g., when we hit a lambda). In those situations, we need to keep around the substitution that we promised to do. This pair, of a substitution and a terms, is known as a closure. In what follows, we give call-by-name and call-by-value, environment-based semantics.

We need a way to represent closures -- at this point, it's useful to break out values as a distinct category. We could simplify this definition by getting rid of the Num_v case and just carry around a substitution, but that's a little less traditional.

Here's a more fascinating way to define STLC. We begin by defining a term language that incorporates typing. So you simply cannot build a term that is not well-typed.

Now we give a denotation for our types as Coq Types.

We represent a context as a tuple Type, where we've applied the type interpretation to the type components of the context.

It's going to be a little easier to write this function using tactic mode than doing an explicit bit of programming, at least until I teach you how to do dependent matches. This basically says that given a variable x, context G, and type t, such that G(x) = t, and given a tuple X in the interpretation of G, we can produce a value of type tinterp t. We do so by simply running down the context G and the tuple X in parallel, until we find the variable we are looking for.

So given a typed expression e (under context G and with type t), and given an environment in the interpretation of G, we can produce a value of type t. This is kind of magical, as note that we're essentially proving that evaluation of all simply typed terms always terminates -- if they didn't, then we couldn't write a Coq function to do the evaluation!