So far, we have considered a variety of pure language features, including functional abstraction, basic types such as numbers and booleans, and structured types such as records and variants. These features form the backbone of most programming languages---including purely functional languages such as Haskell, ``mostly functional'' languages such as ML, imperative languages such as C, and object-oriented languages such as Java. Most practical programming languages also include various impure features that cannot be described in the simple semantic framework we have used so far. In particular, besides just yielding results, evaluation of terms in these languages may assign to mutable variables (reference cells, arrays, mutable record fields, etc.), perform input and output to files, displays, or network connections, make non-local transfers of control via exceptions, jumps, or continuations, engage in inter-process synchronization and communication, and so on. In the literature on programming languages, such ``side effects'' of computation are more generally referred to as computational effects. In this chapter, we'll see how one sort of computational effect---mutable references---can be added to the calculi we have studied. The main extension will be dealing explicitly with a store (or heap). This extension is straightforward to define; the most interesting part is the refinement we need to make to the statement of the type preservation theorem.

Preliminaries

We need to repeat the definition of the solve by inversion tactic here so that we don't need to import all of Stlc.v. It really belongs in SfLib.v.

Records

(This subsection and the next belong in MoreStlc.v; should be moved there for next year.) Another familiar structure from everyday programming languages is records. Intuitively, these are n-ary products with labeled fields. Syntax:

       t ::=                          Terms:
           | ...
           | {i1=t1, ..., in=tn}         record 
           | t.i                         projection

       v ::=                          Values:
           | ...
           | {i1=v1, ..., in=vn}         record value

       T ::=                          Types:
           | ...
           | {i1:T1, ..., in:Tn}         record type

Intuitively, the generalization is pretty obvious. But it's worth noticing that what we've actually written is rather informal: in particular, we've written "..." in several places to mean "any number of these," and we've omitted explicit mention of the usual side-condition that the labels of a record should not contain repetitions. It is possible to devise informal notations that are more precise, but these tend to be quite heavy and to obscure the main points of the definitions. So we'll leave these a bit loose here (they are informal anyway, after all) and do the work of tightening things up elsewhere (in Records.v). Reduction:

ti --> ti'	(ST_Rcd)
{i1=v1, ..., im=vm, in=ti, ...} -->
{i1=v1, ..., im=vm, in=ti', ...}

t1 --> t1'	(ST_Proj1)
t1.i --> t1'.i

	(ST_ProjRcd)
{..., i=vi, ...}.i --> vi

Again, these rules are a bit informal. For example, the first rule is intended to be read "if ti is the leftmost field that is not a value and if ti steps to ti', then the whole record steps..." In the last rule, the intention is that there should only be one field called i, and that all the other fields must contain values. Typing:

Gamma |- t1 : T1     ...     Gamma |- tn : Tn	(T_Rcd)
Gamma |- {i1=t1, ..., in=tn} : {i1:T1, ..., in:Tn}

Gamma |- t : {..., i:Ti, ...}	(T_Proj)
Gamma |- t.i : Ti

Encoding Records

There are several ways to make the above definitions precise.

• We can directly formalize the syntactic forms and inference rules, staying as close as possible to the form we've given them above. This is conceptually straightforward, and it's what we'd want to do if we were building a real compiler -- in particular, it will allow is to print error messages in the form that programmers will find easy to understand. But the formal versions of the rules will not be very pretty!
• We could look for a smoother way of presenting records -- for example, a binary presentation with one constructor for the empty record and another constructor for adding a single field to an existing record, instead of a single monolithic constructor that builds a whole record at once. This is the right way to go if we are primarily interested in studying the metatheory of the calculi with records, since it leads to clean and elegant definitions and proofs. The file Records.v shows how this can be done.
• Alternatively, if we like, we can avoid formalizing records altogether, by stipulating that record notations are just informal shorthands for more complex expressions involving pairs and product types. We sketch this approach here.

First, observe that we can encode arbitrary-size tuples using nested pairs and the unit value. To avoid overloading the pair notation (t1,t2), we'll use curly braces without labels to write down tuples, so {} is the empty tuple, {5} is a singleton tuple, {5,6} is a 2-tuple (morally the same as a pair), {5,6,7} is a triple, etc.

    {}                 ---->  unit
    {t1, t2, ..., tn}  ---->  (t1, trest)
                              where {t2, ..., tn} ----> trest

Similarly, we can encode tuple types using nested product types:

    {}                 ---->  Unit
    {T1, T2, ..., Tn}  ---->  (T1, TRest)
                              where {T2, ..., Tn} ----> TRest

The operation of projecting a field from a tuple can be encoded using a sequence of second projections followed by a first projection:

    t.0        ---->  t.fst
    t.(n+1)    ---->  (t.snd).n

Next, suppose that there is some total ordering on record labels, so that we can associate each label with a unique natural number. This number is called the position of the label. For example, we might assign positions like this:

      LABEL   POSITION
      a       0
      b       1
      c       2
      ...     ...
      foo     1004
      ...     ...
      bar     10562
      ...     ...

We use these positions to encode record values as tuples (i.e., as nested pairs) by sorting the fields according to their positions. For example:

      {a=5, b=6}      ---->   {5,6}
      {a=5, c=7}      ---->   {5,unit,7}
      {c=7, a=5}      ---->   {5,unit,7}
      {c=5, b=3}      ---->   {unit,3,5}
      {f=8,c=5,a=7}   ---->   {7,unit,5,unit,unit,8}
      {f=8,c=5}       ---->   {unit,unit,5,unit,unit,8}

Note that each field appears in the position associated with its label, that the size of the tuple is determined by the label with the highest position, and that we fill in unused positions with unit. We do exactly the same thing with record types:

      {a:Nat, b:Nat}      ---->   {Nat,Nat}
      {c:Nat, a:Nat}      ---->   {Nat,Unit,Nat}
      {f:Nat,c:Nat}       ---->   {Unit,Unit,Nat,Unit,Unit,Nat}

Finally, record projection is encoded as a tuple projection from the appropriate position:

      t.l  ---->  t.(position of l)

It is not hard to check that all the typing and reduction rules for the original "direct" presentation of records are validated by this encoding. Of course, this encoding will not be very efficient if we happen to use a record with label bar! But things are not actually as bad as they might seem: for example, if we assume that our compiler can see the whole program at the same time, we can choose the numbering of labels so that we assign small positions to the most frequently used labels. Indeed, there are industrial compilers that essentially do this!

Mutable References

Nearly every programming language provides some form of assignment operation that changes the contents of a previously allocated piece of storage. In some languages---notably ML and its relatives---the mechanisms for name-binding and those for assignment are kept separate. We can have a variable x whose value is the number 5, or we can have a variable y whose value is a reference (or pointer) to a mutable cell whose current contents is 5, and the difference is visible to the programmer. We can add x to another number, but not assign to it. We can use y directly to assign a new value to the cell that it points to (by writing y:=84), but we cannot use it directly as an argument to plus. Instead, we must explicitly dereference it, writing !y to obtain its current contents. In most other languages---in particular, in all members of the C family, including Java---every variable name refers to a mutable cell, and the operation of dereferencing a variable to obtain its current contents is implicit. For purposes of formal study, it is useful to keep these mechanisms separate; our development in this chapter will closely follow ML's model. Applying the lessons learned here to C-like languages is a straightforward matter of collapsing some distinctions and rendering certain operations such as dereferencing implicit instead of explicit. In this chapter, we study adding mutable references to the simply-typed lambda calculus with natural numbers. The main extension will be dealing explicitly with a store (or heap). This extension is straightforward to define; the most interesting part is the refinement we need to make to the statement of the type preservation theorem.

Syntax

The basic operations on references are allocation, dereferencing, and assignment.

• To allocate a reference, we use the ref operator, providing an initial value for the new cell. For example, ref 5 creates a new cell containing the value 5, and evaluates to a reference to that cell.
• To read the current value of this cell, we use the dereferencing operator !; for example, !(ref 5) evaluates to 5.
• To change the value stored in a cell, we use the assignment operator. If r is a reference, r := 7 will store the value 7 in the cell referenced by r. However, r := 7 evaluates to the trivial value unit; it exists only to have the side effect of modifying the contents of a cell.

Types

We will start with the simply typed lambda calculus over the natural numbers. To the base natural number type and arrow types we need to add two more types to deal with references. First, we need the unit type, which we will use as the result type of an assignment operation. We then add reference types. If T is a type, then Ref T is the type of references which point to a cell holding values of type T.

Terms

Besides variables, abstractions, applications, natural-number-related terms, and unit, we need four more sorts of terms in order to handle mutable references:

• tm_ref t1, informally written ref t1, allocates a new reference cell with the value t1 and evaluates to the location of the newly allocated cell;
• tm_deref t1, informally !t1, evaluates to the contents of the cell referenced by t1;
• tm_assign t1 t2, informally t1 := t2, assigns t2 to the cell referenced by t1; and
• tm_loc l represents a reference to the cell at location l. We'll discuss locations later.

In informal examples, we'll also freely use the extensions of the STLC developed in the MoreStlc chapter; to keep the proofs small, we won't bother formalizing them again here. (It would be easy to do so, though, since there are no very interesting interactions between those features and references.)

Typing (Preview)

Informally, the typing rules for allocation, dereferencing, and assignment will look like this:

Gamma |- t1 : T1	(T_Ref)
Gamma |- ref t1 : Ref T1

Gamma |- t1 : Ref T11	(T_Deref)
Gamma |- !t1 : T11

Gamma |- t1 : Ref T11
Gamma |- t2 : T11	(T_Assign)
Gamma |- t1 := t2 : Unit

The rule for locations will require a bit more machinery, and this will motivate some changes to the other rules; we'll come back to this later.

Values and Substitution

In addition to abstractions and numbers, we have two new types of values: the unit value, and locations.

Extending substitution to handle the new syntax of terms is straightforward.

Pragmatics

Side Effects and Sequencing

The fact that the result of an assignment expression is the trivial value unit allows us to use a nice abbreviation for sequencing. For example, we can write

       r:=succ(!r); !r

as an abbreviation for

       (\x:Unit. !r) (r := succ(!r)).

This has the effect of evaluating two expressions in order and returning the value of the second. Restricting the type of the first expression to Unit helps the typechecker to catch some silly errors by permitting us to throw away the first value only if it is really guaranteed to be trivial. Notice that, if the second expression is also an assignment, then the type of the whole sequence will be Unit, so we can validly place it to the left of another ; to build longer sequences of assignments:

       r:=succ(!r); r:=succ(!r); r:=succ(!r); r:=succ(!r); !r

Formally, we introduce sequencing as a "derived form" tm_seq that expands into an abstraction and an application.

(If we were building a full-blown programming language instead of just a theoretical model, this derived form could be implemented by giving the parser a separate rule for expressions of the form t1;t2 but expanding such expressions into an abstraction and an application instead of defining a separate tm_seq constructor for the abstract syntax tree datatype.)

References and Aliasing

It is important to bear in mind the difference between the reference that is bound to r and the cell in the store that is pointed to by this reference. If we make a copy of r, for example by binding its value to another variable s, what gets copied is only the reference, not the contents of the cell itself. For example, after evaluating

      let r = ref 5 in
      let s = r in
      s := 82;
      (!r)+1

the cell referenced by r will contain the value 82, which will also be the result of the whole expression. The references r and s are said to be aliases for the same cell. The possibility of aliasing can make programs with references quite tricky to reason about. For example, the expression

      r := 1; r := !s

assigns 1 to r and then immediately overwrites it with s's current value; this has exactly the same effect as the single assignment

      r:=!s

unless we happen to do it in a context where r and s are aliases for the same cell! Of course, aliasing is also a large part of what makes references useful! In particular, it allows us to set up "implicit communication channels"---shared state---between different parts of a program.

Shared State

The possibility of aliasing can make programs with references quite tricky to reason about. For example, the expression (r:=1; r:=!s), which assigns 1 to r and then immediately overwrites it with s's current value, has exactly the same effect as the single assignment r:=!s, unless we write it in a context where r and s are aliases for the same cell. Of course, aliasing is also a large part of what makes references useful. In particular, it allows us to set up ``implicit communication channels''---shared state---between different parts of a program. For example, suppose we define a reference cell and two functions that manipulate its contents:

    let c = ref 0 in
    let incc = \_:Unit. (c := succ (!c); !c) in
    let decc = \_:Unit. (c := pred (!c); !c) in
    ...

Note that, since their argument types are Unit, the abstractions in the definitions of incc and decc are not providing any useful information to the bodies of the functions (using the wildcard _ as the name of the bound variable is a reminder of this). Instead, their purpose is to "slow down" the execution of the function bodies: since function abstractions are values, the two lets are executed simply by binding these functions to the names incc and decc, rather than by actually incrementing or decrementing c. Later, each call to one of these functions results in its body being executed once and performing the appropriate mutation on c. Such functions are often called thunks. In the context of these declarations, calling incc results in changes to c that can be observed by calling decc. For example, if we replace the ... with (incc unit; incc unit; decc unit), the result of the whole program will be 1.

Objects

We can go a step further and write a function that creates c, incc, anbd decc, packages incc and decc together into a record, and returns this record:

    newcounter = 
        \_:Unit.
           let c = ref 0 in
           let incc = \_:Unit. (c := succ (!c); !c) in
           let decc = \_:Unit. (c := pred (!c); !c) in
           {i=incc, d=decc}

Now, each time we call newcounter, we get a new record of functions that share access to the same storage cell c. The caller of newcounter can't get at this storage cell directly, but can affect it indirectly by calling the two functions. In other words, we've created a simple form of object.

    let c1 = newcounter unit in
    let c2 = newcounter unit in
    // Note that we've allocated two separate storage cells now!
    let r1 = c1.i unit in
    let r2 = c2.i unit in
    r2  // yields 1, not 2!

Exercise: 1 star

Draw (on paper) the contents of the store at the point in execution where the first two lets have finished and the third one is about to begin.

☐

References to Compound Types

A reference cell need not contain just a number: the primitives we've defined above allow us to create references to values of any type, including functions. For example, we can use references to functions to give a (not very efficient) implementation of arrays of numbers, as follows. Write NatArray for the type Ref (Nat->Nat). Begin by defining a useful helper function:

    equal = 
      fix 
        (\eq:Nat->Nat->Bool.
           \m:Nat. \n:Nat.
             if m=0 then iszero n 
             else if n=0 then false
             else eq (pred m) (pred n))

Now, to build a new array, we allocate a reference cell and fill it with a function that, when given an index, always returns 0.

    newarray = \_:Unit. ref (\n:Nat.0)

To look up an element of an array, we simply apply the function to the desired index.

    lookup = \a:NatArray. \n:Nat. (!a) n

The interesting part of the encoding is the update function. It takes an array, an index, and a new value to be stored at that index, and does its job by creating (and storing in the reference) a new function that, when it is asked for the value at this very index, returns the new value that was given to update, and on all other indices passes the lookup to the function that was previously stored in the reference.

    update = \a:NatArray. \m:Nat. \v:Nat. 
                 let oldf = !a in
                 a := (\n:Nat. if equal m n then v else oldf n);

References to values containing other references can also be very useful, allowing us to define data structures such as mutable lists and trees.

Exercise: 2 stars

If we defined update more compactly like this

    update = \a:NatArray. \m:Nat. \v:Nat. 
                a := (\n:Nat. if equal m n then v else (!a) n)

would it behave the same?

☐

Garbage Collection

A last issue that we should mention before we move on with formalizing references is storage de-allocation. We have not provided any primitives for freeing reference cells when they are no longer needed. Instead, like many modern languages (including ML and Java) we rely on the run-time system to perform garbage collection, collecting and reusing cells that can no longer be reached by the program. This is not just a question of taste in language design: it is extremely difficult to achieve type safety in the presence of an explicit deallocation operation. The reason for this is the familiar dangling reference problem: we allocate a cell holding a number, save a reference to it in some data structure, use it for a while, then deallocate it and allocate a new cell holding a boolean, possibly reusing the same storage. Now we can have two names for the same storage cell---one with type Ref Nat and the other with type Ref Bool.

Exercise: 1 star

Show how this can lead to a violation of type safety.

☐

Operational Semantics

Locations

The most subtle aspect of the treatment of references appears when we consider how to formalize their operational behavior. One way to see why is to ask, ``What should be the values of type Ref T?'' The crucial observation that we need to take into account is that evaluating a ref operator should do something---namely, allocate some storage---and the result of the operation should be a reference to this storage. What, then, is a reference? The run-time store in most programming language implementations is essentially just a big array of bytes. The run-time system keeps track of which parts of this array are currently in use; when we need to allocate a new reference cell, we allocate a large enough segment from the free region of the store (4 bytes for integer cells, 8 bytes for cells storing Floats, etc.), mark it as being used, and return the index (typically, a 32- or 64-bit integer) of the start of the newly allocated region. These indices are references. For present purposes, there is no need to be quite so concrete. We can think of the store as an array of values, rather than an array of bytes, abstracting away from the different sizes of the run-time representations of different values. A reference, then, is simply an index into the store. (If we like, we can even abstract away from the fact that these indices are numbers, but for purposes of formalization in Coq it is a bit more convenient to use numbers.) We'll use the word location instead of reference or pointer from now on to emphasize this abstract quality. (Treating locations abstractly in this way will prevent us from modeling the pointer arithmetic found in low-level languages such as C. This limitation is intentional. While pointer arithmetic is occasionally very useful, especially for implementing low-level components of run-time systems, such as garbage collectors, it cannot be tracked by most type systems: knowing that location n in the store contains a float doesn't tell us anything useful about the type of location n+4. In C, pointer arithmetic is a notorious source of type safety violations.)

Stores

Recall that, in the small-step operational semantics for IMP, the step relation needed to carry along an auxiliary state in addition to the program being executed. In the same way, once we have added reference cells to the STLC, our step relation must carry along a store to keep track of the contents of reference cells. We could reuse the same functional representation we used for states in IMP, but for carrying out the proofs it is actually more convenient to simply use a list of values to represent stores. In IMP, the programmer could decide which variable to modify, so states had to be ready to map any collection of variables to values. However, in the STLC with references, the programmer has no control over which location is used for a new reference; the only way to create a reference cell is with tm_ref t1, which puts the value t1 in a new reference cell and evaluates to the location of the reference cell it has chosen. So we can just add a new reference cell to the end of the list representing the store each time a tm_ref is encountered.

We use store_lookup n st to retrieve the value of the reference cell at location n in the store st. Note that we must give a default value to nth in case we try looking up an index which is too large. (In fact, we will never actually do this, but proving it will of course require some work!)

To add a new reference cell to the store, we use snoc.

We will need some boring lemmas about snoc. The proofs are routine inductions.

To update the store, we use the replace function, which replaces the contents of a cell at a particular index.

Of course, we also need some boring lemmas about replace, which are also fairly straightforward to prove.

Reduction

Next, we need to extend our operational semantics to take stores into account. Since the result of evaluating an expression will in general depend on the contents of the store in which it is evaluated, the evaluation rules should take not just a term but also a store as argument. Furthermore, since the evaluation of a term may cause side effects on the store that may affect the evaluation of other terms in the future, the evaluation rules need to return a new store. Thus, the shape of the single-step evaluation relation changes from t --> t' to t / st --> t' / st', where st and st' are the starting and ending states of the store. To carry through this change, we first need to augment all of our existing evaluation rules with stores:

value v2	(ST_AppAbs)
(\a:T.t12) v2 / st --> [v2/a]t12 / st

t1 / st --> t1' / st'	(ST_App1)
t1 t2 / st --> t1' t2 / st'

value v1     t2 / st --> t2' / st'	(ST_App2)
v1 t2 / st --> v1 t2' / st'

Note that the first rule here returns the store unchanged: function application, in itself, has no side effects. The other two rules simply propagate side effects from premise to conclusion. Now, the result of evaluating a ref expression will be a fresh location; this is why we included locations in the syntax of terms and in the set of values. Of course, making this extension to the syntax of terms does not mean that we intend programmers to write terms involving explicit, concrete locations: such terms will arise only as intermediate results of evaluation. In terms of this expanded syntax, we can state evaluation rules for the new constructs that manipulate locations and the store. First, to evaluate a dereferencing expression !t1, we must first reduce t1 until it becomes a value:

t1 / st --> t1' / st'	(ST_Deref)
!t1 / st --> !t1' / st'

Once t1 has finished reducing, we should have an expression of the form !l, where l is some location. (A term that attempts to dereference any other sort of value, such as a function or unit, is erroneous, as is a term that tries to derefence a location that is larger than the size |st| of the currently allocated store; the evaluation rules simply get stuck in this case. The type safety properties that we'll establish below assure us that well-typed terms will never misbehave in this way.)

l < |st|	(ST_DerefLoc)
!(loc l) / st --> lookup l st / st

Next, to evaluate an assignment expression t1:=t2, we must first evaluate t1 until it becomes a value (a location), and then evaluate t2 until it becomes a value (of any sort):

t1 / st --> t1' / st'	(ST_Assign1)
t1 := t2 / st --> t1' := t2 / st'

t2 / st --> t2' / st'	(ST_Assign2)
t1 := t2 / st --> t1 := t2' / st'

Once we have finished with t1 and t2, we have an expression of the form l:=v2, which we execute by updating the store to make location l contain v2:

l < |st|	(ST_Assign)
loc l := v2 / st --> unit / [v2/l]st

The notation [v2/l]st means ``the store that maps l to v2 and maps all other locations to the same thing as st.'' Note that the term resulting from this evaluation step is just unit; the interesting result is the updated store.) Finally, to evaluate an expression of the form ref t1, we first evaluate t1 until it becomes a value:

t1 / st --> t1' / st'	(ST_Ref)
ref t1 / st --> ref t1' / st'

Then, to evaluate the ref itself, we choose a fresh location at the end of the current store -- i.e., location |st| -- and yield a new store that extends st with the new value v1.

	(ST_RefValue)
ref v1 / st --> loc |st| / st,v1

The value resulting from this step is the newly allocated location itself. (Formally, st,v1 means snoc st v1.) Note that these evaluation rules do not perform any kind of garbage collection: we simply allow the store to keep growing without bound as evaluation proceeds. This does not affect the correctness of the results of evaluation (after all, the definition of ``garbage'' is precisely parts of the store that are no longer reachable and so cannot play any further role in evaluation), but it means that a naive implementation of our evaluator might sometimes run out of memory where a more sophisticated evaluator would be able to continue by reusing locations whose contents have become garbage. Formally...

Typing

Contexts

Our contexts for free variables will be exactly the same as for the STLC.

Store typings

Having extended our syntax and evaluation rules to accommodate references, our last job is to write down typing rules for the new constructs---and, of course, to check that they are sound. Naturally, the key question is, "What is the type of a location?" When we evaluate a term containing concrete locations, the type of the result depends on the contents of the store that we start with. For example, if we evaluate the term !(loc 1) in the store [unit, unit], the result is unit; if we evaluate the same term in the store [unit, \x:Unit.x], the result is \x:Unit.x. With respect to the former store, the location 1 has type Unit, and with respect to the latter it has type Unit->Unit. This observation leads us immediately to a first attempt at a typing rule for locations:

Gamma |- lookup l st : T1
Gamma |- loc l : Ref T1

That is, to find the type of a location l, we look up the current contents of l in the store and calculate the type T1 of the contents. The type of the location is then Ref T1. Having begun in this way, we need to go a little further to reach a consistent state. In effect, by making the type of a term depend on the store, we have changed the typing relation from a three-place relation (between contexts, terms, and types) to a four-place relation (between contexts, stores, terms, and types). Since the store is, intuitively, part of the context in which we calculate the type of a term, let's write this four-place relation with the store to the left of the turnstile: Gamma; st |- t : T. Our rule for typing references now has the form

Gamma; st |- lookup l st : T1
Gamma; st |- loc l : Ref T1

and all the rest of the typing rules in the system are extended similarly with stores. The other rules do not need to do anything interesting with their stores---just pass them from premise to conclusion. However, there are two problems with this rule. First, typechecking is rather inefficient, since calculating the type of a location l involves calculating the type of the current contents v of l. If l appears many times in a term t, we will re-calculate the type of v many times in the course of constructing a typing derivation for t. Worse, if v itself contains locations, then we will have to recalculate their types each time they appear. Second, the proposed typing rule for locations may not allow us to derive anything at all, if the store contains a cycle. For example, there is no finite typing derivation for the location 0 with respect to this store:

   [\x:Nat. (!(loc 1)) x, \x:Nat. (!(loc 0)) x]

Exercise: 2 stars

Can you find a term whose evaluation will create this particular cyclic store? ☐ Both of these problems arise from the fact that our proposed typing rule for locations requires us to recalculate the type of a location every time we mention it in a term. But this, intuitively, should not be necessary. After all, when a location is first created, we know the type of the initial value that we are storing into it. Moreover, although we may later store other values into this location, those other values will always have the same type as the initial one. In other words, we always have in mind a single, definite type for every location in the store, which is fixed when the location is allocated. These intended types can be collected together as a store typing---a finite function mapping locations to types. Just like we did for stores, we will represent a store type simply as a list of types: the type at index i records the type of the value stored in cell i.

The store_ty_lookup function retrieves the type at a particular index.

Suppose we are given a store typing ST describing the store st in which some term t will be evaluated. Then we can use ST to calculate the type of the result of t without ever looking directly at st. For example, if ST is [Unit, Unit->Unit], then we may immediately infer that !(loc 1) has type Unit->Unit. More generally, the typing rule for locations can be reformulated in terms of store typings like this:

l < |ST|
Gamma; ST |- loc l : Ref (lookup l st)

That is, as long as l is a valid location (it is less than the length of ST), we can compute the type of l just by looking it up in ST. Typing is again a four-place relation, but it is parameterized on a store typing rather than a concrete store. The rest of the typing rules are analogously augmented with store typings.

The Typing Relation

We can now give the typing relation for the STLC with references. The rules for variables, abstraction, and application are the same as before (with the addition of a store typing which is ignored).

	(T_Unit)
Gamma; ST |- unit : Unit

l < |ST|	(T_Loc)
Gamma; ST |- loc l : Ref (lookup l st)

Gamma; ST |- t1 : T1	(T_Ref)
Gamma; ST |- ref t1 : Ref T1

Gamma; ST |- t1 : Ref T11	(T_Deref)
Gamma; ST |- !t1 : T11

Gamma; ST |- t1 : Ref T11
Gamma; ST |- t2 : T11	(T_Assign)
Gamma; ST |- t1 := t2 : Unit

Of course, these typing rules will accurately predict the results of evaluation only if the concrete store used during evaluation actually conforms to the store typing that we assume for purposes of typechecking. This proviso exactly parallels the situation with free variables in the STLC: the substitution lemma promises us that, if Gamma |- t : T, then we can replace the free variables in t with values of the types listed in Gamma to obtain a closed term of type T, which, by the type preservation theorem will evaluate to a final result of type T if it yields any result at all. We will see later how to formalize an analogous intuition for stores and store typings. Finally, note that, for purposes of typechecking the terms that programmers actually write, we do not need to do anything tricky to guess what store typing we should use. Concrete location constants arise only in terms that are the intermediate results of evaluation; they are not in the language that programmers write. Thus, we can simply typecheck the programmer's terms with respect to the empty store typing. As evaluation proceeds and new locations are created, we will always be able to see how to extend the store typing by looking at the type of the initial values being placed in newly allocated cells; this intuition is formalized in the statement of the type preservation theorem below.

Safety

Our final task is to check that standard type safety properties continue to hold for the STLC with references. The progress theorem ("well-typed terms are not stuck") can be stated and proved almost as for the STLC; we just need to add a few straightforward cases to the proof, dealing with the new constructs. The preservation theorem is a bit more interesting, so let's look at it first.

Well Typed Stores

Since we have extended both the evaluation relation (with initial and final stores) and the typing relation (with a store typing), we need to change the statement of preservation to include these parameters. Clearly, though, we cannot just add stores and store typings without saying anything about how they are related:

If we typecheck with respect to some set of assumptions about the types of the values in the store and then evaluate with respect to a store that violates these assumptions, the result will be disaster. We say that a store st is well typed with repsect to a typing context Gamma and a store typing ST if the term at each location l in st has the type at location l in ST. The following definition of store_well_typed formalizes this.

Informally, we will write Gamma; ST |- st for store_well_typed Gamma ST st. Intuitively, a store st is consistent with a store typing ST if every value in the store has the type predicted by the store typing. (The only subtle point is the fact that, when typing the values in the store, we supply the very same store typing to the typing relation!)

Exercise: 2 stars

Can you find a context Gamma, a store st, and two different store typings ST1 and ST2 such that both Gamma; ST1 |- st and Gamma; ST2 |- st?

☐ We can now state something closer to the desired preservation property:

This statement is fine for all of the evaluation rules except the allocation rule ST_RefValue. The problem is that this rule yields a store with a larger domain than the initial store, which falsifies the conclusion of the above statement: if ST' includes a binding for a fresh location l, then l cannot be in the domain of ST, and it will not be the case that t' (which definitely mentions l) is typable under ST.

Extending Store Typings

Evidently, since the store can increase in size during evaluation, we need to allow the store typing to grow as well. This motivates the following definition. We say that the store type ST' extends ST if ST' is just ST with some new types added to the end.

We'll need a few lemmas about extended contexts. First, looking up a type in an extended store typing yields the same result as in the original:

If ST' extends ST, the length of ST' is at least that of ST.

Finally, snoc ST T extends ST, and extends is reflexive.

Preservation, Finally

We can now give the final (correct) statement of the type preservation property: Note that the preservation theorem merely asserts that there is some store typing ST' extending ST (i.e., agreeing with ST on the values of all the old locations) such that the new term t' is well typed with respect to ST'; it does not tell us exactly what ST' is. It is intuitively clear, of course, that ST' is either ST or else it is exactly snoc ST T1, where T1 is the type of the value v1 in the extended store snoc st v1, but stating this explicitly would complicate the statement of the theorem without actually making it any more useful: the weaker version above is already in the right form (because its conclusion implies its hypothesis) to "turn the crank" repeatedly and conclude that every sequence of evaluation steps preserves well-typedness. Combining this with the progress property, we obtain the usual guarantee that "well-typed programs never go wrong." Before we actually get around to proving this, we'll need a few lemmas.

Substitution lemma

First, we need an easy extension of the standard substitution lemma, along with the same machinery about context invariance that we used in the proof of the substitution lemma for the STLC.

Assignment Preserves Store Typing

Next, we must show that replacing the contents of a cell in the store with a new value of appropriate type does not change the overall type of the store.

Weakening for Stores

Finally, we need a kind of "weakening" lemma for stores, stating that, if a store is extended with a new location, the extended store still allows us to assign types to all the same terms as the original.

We can also use the weakening lemma for stores to prove that if a store is well-typed with respect to a store typing, then the store extended with a new term t will still be well-typed with respect to the store typing extended with t's type.

Preservation!

Now that we've got everything set up right, the proof of preservation is actually straightforward.

Progress

Fortunately, progress remains relatively easy to prove; the proof is very similar to the proof of progress for the STLC, with a few new cases for the new syntactic constructs.

References and Nontermination

We noted (but did not prove) that the simply typed lambda calculus is normalizing, that is, every well-typed term can be reduced to a value in a finite number of steps. What about STLC + references? Surprisingly, adding references causes us to lose the normalization property: there exist well-typed terms in the STLC + references which can continue to reduce forever, without ever reaching a normal form! How can we construct such a term? The main idea is to make a function which calls itself. We first make a function which calls another function stored in a reference cell; the trick is that we then smuggle in a reference to itself!

   (\r:Ref (Unit -> Unit). 
        r := (\x:Unit.(!r) unit); (!r) unit) 
   (ref (\x:Unit.unit))

First, ref (\x:Unit.unit) creates a reference to a cell of type Unit -> Unit. We then pass this reference as the argument to a function which binds it to the name r, and assigns to it the function (\x:Unit.(!r) unit) --- that is, the function which ignores its argument and calls the function stored in r on the argument unit; but of course, that function is itself! To get the ball rolling we finally execute this function with (!r) unit.

This term is well-typed:

To show formally that the term diverges, we first define the step_closure of the single-step reduction relation, written -->+. This is just like the reflexive step closure of single-step reduction (which we're been writing -->*), except that it is not reflexive: t -->+ t' means that t can reach t' by one or more steps of reduction.

Now, we can show that the expression loop reduces to the expression !(loc 0) unit and the size-one store [(loc 0) / r] loop_fun.

Finally, the latter expression reduces in two steps to itself!

Exercise: 4 stars

Use the above ideas to implement a factorial function in STLC with references. (There is no need to prove formally that it really behaves like the factorial. Just use the example below to make sure it gives the correct result when applied to the argument 4.)

If your definition is correct, you should be able to just uncomment the example below; the proof should be fully automatic using the following tactic.

Lemma factorial_4 : exists st, 
  tm_app factorial (tm_nat 4) / [] -->* tm_nat 24 / st.
Proof.
  eexists. unfold factorial.
  normalize.
Qed.

☐

Additional Exercises

Exercise: 5 stars, optional

Challenge problem: modify our formalization to include an account of garbage collection, and prove that it satisfies whatever nice properties you can think to prove about it. ☐