程序代写代做代考 scheme assembly flex algorithm file system Fortran Java ada prolog case study computer architecture c++ Excel database Lambda Calculus ocaml interpreter Erlang concurrency Haskell AI compiler Hive discrete mathematics data structure chain top.dvi

| ⇒ y.name;

ñ getName : Addr → String

The formal definition of variants is given in Figure 11-11. Note that, as with

records in §11.8, the order of labels in a variant type is significant here.

11.10 Variants 137

Options

One very useful idiom involving variants is optional values. For example, an

element of the type

OptionalNat = ;

is either the trivial unit value with the tag none or else a number with the tag

some—in other words, the type OptionalNat is isomorphic to Nat extended

with an additional distinguished value none. For example, the type

Table = Nat→OptionalNat;

represents finite mappings from numbers to numbers: the domain of such a

mapping is the set of inputs for which the result is for some n. The

empty table

emptyTable = λn:Nat. as OptionalNat;

ñ emptyTable : Table

is a constant function that returns none for every input. The constructor

extendTable =

λt:Table. λm:Nat. λv:Nat.

λn:Nat.

if equal n m then as OptionalNat

else t n;

ñ extendTable : Table → Nat → Nat → Table

takes a table and adds (or overwrites) an entry mapping the input m to the

output . (The equal function is defined in the solution to Exer-

cise 11.11.1 on page 510.)

We can use the result that we get back from a Table lookup by wrapping a

case around it. For example, if t is our table and we want to look up its entry

for 5, we might write

x = case t(5) of

⇒ 999

| ⇒ v;

providing 999 as the default value of x in case t is undefined on 5.

Many languages provide built-in support for options. OCaml, for exam-

ple, predefines a type constructor option, and many functions in typical

OCaml programs yield options. Also, the null value in languages like C, C++,

and Java is actually an option in disguise. A variable of type T in these lan-

guages (where T is a “reference type”—i.e., something allocated in the heap)

138 11 Simple Extensions

can actually contain either the special value null or else a pointer to a T

value. That is, the type of such a variable is really Ref(Option(T)), where

Option(T) = . Chapter 13 discusses the Ref construc-

tor in detail.

Enumerations

Two “degenerate cases” of variant types are useful enough to deserve special

mention: enumerated types and single-field variants.

An enumerated type (or enumeration) is a variant type in which the field

type associated with each label is Unit. For example, a type representing the

days of the working week might be defined as:

Weekday = ;

The elements of this type are terms like as Weekday. Indeed,

since the type Unit has only unit as a member, the type Weekday is inhabited

by precisely five values, corresponding one-for-one with the days of the week.

The case construct can be used to define computations on enumerations.

nextBusinessDay = λw:Weekday.

case w of ⇒ as Weekday

| ⇒ as Weekday

| ⇒ as Weekday

| ⇒ as Weekday

| ⇒ as Weekday;

Obviously, the concrete syntax we are using here is not well tuned for making

such programs easy to write or read. Some languages (beginning with Pascal)

provide special syntax for declaring and using enumerations. Others—such

as ML, cf. page 141—make enumerations a special case of the variants.

Single-Field Variants

The other interesting special case is variant types with just a single label l:

V = ;

Such a type might not seem very useful at first glance: after all, the elements

of V will be in one-to-one correspondence with the elements of the field type

T, since every member of V has precisely the form for some t : T.

What’s important, though, is that the usual operations on T cannot be applied

to elements of V without first unpackaging them: a V cannot be accidentally

mistaken for a T.

11.10 Variants 139

For example, suppose we are writing a program to do financial calculations

in multiple currencies. Such a program might include functions for converting

between dollars and euros. If both are represented as Floats, then these

functions might look like this:

dollars2euros = λd:Float. timesfloat d 1.1325;

ñ dollars2euros : Float → Float

euros2dollars = λe:Float. timesfloat e 0.883;

ñ euros2dollars : Float → Float

(where timesfloat : Float→Float→Float multiplies floating-point num-

bers). If we then start with a dollar amount

mybankbalance = 39.50;

we can convert it to euros and then back to dollars like this:

euros2dollars (dollars2euros mybankbalance);

ñ 39.49990125 : Float

All this makes perfect sense. But we can just as easily perform manipulations

that make no sense at all. For example, we can convert my bank balance to

euros twice:

dollars2euros (dollars2euros mybankbalance);

ñ 50.660971875 : Float

Since all our amounts are represented simply as floats, there is no way that

the type system can help prevent this sort of nonsense. However, if we define

dollars and euros as different variant types (whose underlying representa-

tions are floats)

DollarAmount = ;

EuroAmount = ;

then we can define safe versions of the conversion functions that will only

accept amounts in the correct currency:

dollars2euros =

λd:DollarAmount.

case d of ⇒

as EuroAmount;

ñ dollars2euros : DollarAmount → EuroAmount

140 11 Simple Extensions

euros2dollars =

λe:EuroAmount.

case e of ⇒

as DollarAmount;

ñ euros2dollars : EuroAmount → DollarAmount

Now the typechecker can track the currencies used in our calculations and

remind us how to interpret the final results:

mybankbalance = as DollarAmount;

euros2dollars (dollars2euros mybankbalance);

ñ as DollarAmount : DollarAmount

Moreover, if we write a nonsensical double-conversion, the types will fail to

match and our program will (correctly) be rejected:

dollars2euros (dollars2euros mybankbalance);

ñ Error: parameter type mismatch

Variants vs. Datatypes

A variant type T of the form is roughly analogous to the ML

datatype defined by:7

type T = l1 of T1

| l2 of T2

| …

| ln of Tn

But there are several differences worth noticing.

1. One trivial but potentially confusing point is that the capitalization con-

ventions for identifiers that we are assuming here are different from those

of OCaml. In OCaml, types must begin with lowercase letters and datatype

constructors (labels, in our terminology) with capital letters, so, strictly

speaking, the datatype declaration above should be written like this:

type t = L1 of t1 | … | Ln of tn

7. This section uses OCaml’s concrete syntax for datatypes, for consistency with implemen-

tation chapters elsewhere in the book, but they originated in early dialects of ML and can be

found, in essentially the same form, in Standard ML as well as in ML relatives such as Haskell.

Datatypes and pattern matching are arguably one of the most useful advantages of these lan-

guages for day to day programming.

11.10 Variants 141

To avoid confusion between terms t and types T, we’ll ignore OCaml’s

conventions for the rest of this discussion and use ours instead.

2. The most interesting difference is that OCaml does not require a type an-

notation when a constructor li is used to inject an element of Ti into the

datatype T: we simply write li(t). The way OCaml gets away with this (and

retains unique typing) is that the datatype T must be declared before it can

be used. Moreover, the labels in T cannot be used by any other datatype

declared in the same scope. So, when the typechecker sees li(t), it knows

that the annotation can only be T. In effect, the annotation is “hidden” in

the label itself.

This trick eliminates a lot of silly annotations, but it does lead to a certain

amount of grumbling among users, since it means that labels cannot be

shared between different datatypes—at least, not within the same module.

In Chapter 15 we will see another way of omitting annotations that avoids

this drawback.

3. Another convenient trick used by OCaml is that, when the type associ-

ated with a label in a datatype definition is just Unit, it can be omitted

altogether. This permits enumerations to be defined by writing

type Weekday = monday | tuesday | wednesday | thursday | friday

for example, rather than:

type Weekday = monday of Unit

| tuesday of Unit

| wednesday of Unit

| thursday of Unit

| friday of Unit

Similarly, the label monday all by itself (rather than monday applied to the

trivial value unit) is considered to be a value of type Weekday.

4. Finally, OCaml datatypes actually bundle variant types together with sev-

eral additional features that we will be examining, individually, in later

chapters.

• A datatype definition may be recursive—i.e., the type being defined is

allowed to appear in the body of the definition. For example, in the

standard definition of lists of Nats, the value tagged with cons is a pair

whose second element is a NatList.

type NatList = nil

| cons of Nat * NatList

142 11 Simple Extensions

• An OCaml datatype can be [parametric data type]parameterizedparametric!data

type on a type variable, as in the general definition of the List datatype:

type ’a List = nil

| cons of ’a * ’a List

Type-theoretically, List can be viewed as a kind of function—called a

type operator—that maps each choice of ′a to a concrete datatype. . .

Nat to NatList, etc. Type operators are the subject of Chapter 29.

Variants as Disjoint Unions

Sum and variant types are sometimes called disjoint unions. The type T1+T2 is

a “union” of T1 and T2 in the sense that its elements include all the elements

from T1 and T2. This union is disjoint because the sets of elements of T1 or

T2 are tagged with inl or inr, respectively, before they are combined, so that

it is always clear whether a given element of the union comes from T1 or T2.

The phrase union type is also used to refer to untagged (non-disjoint) union

types, described in §15.7.

Type Dynamic

Even in statically typed languages, there is often the need to deal with data

whose type cannot be determined at compile time. This occurs in particular

when the lifetime of the data spans multiple machines or many runs of the

compiler—when, for example, the data is stored in an external file system

or database, or communicated across a network. To handle such situations

safely, many languages offer facilities for inspecting the types of values at

run time.

One attractive way of accomplishing this is to add a type Dynamic whose

values are pairs of a value v and a type tag T where v has type T. Instances

of Dynamic are built with an explicit tagging construct and inspected with a

type safe typecase construct. In effect, Dynamic can be thought of as an in-

finite disjoint union, whose labels are types. See Gordon (circa 1980), Mycroft

(1983), Abadi, Cardelli, Pierce, and Plotkin (1991b), Leroy and Mauny (1991),

Abadi, Cardelli, Pierce, and Rémy (1995), and Henglein (1994).

11.11 General Recursion

Another facility found in most programming languages is the ability to de-

fine recursive functions. We have seen (Chapter 5, p. 65) that, in the untyped

11.11 General Recursion 143

lambda-calculus, such functions can be defined with the aid of the fix com-

binator.

Recursive functions can be defined in a typed setting in a similar way. For

example, here is a function iseven that returns true when called with an

even argument and false otherwise:

ff = λie:Nat→Bool.

λx:Nat.

if iszero x then true

else if iszero (pred x) then false

else ie (pred (pred x));

ñ ff : (Nat→Bool) → Nat → Bool

iseven = fix ff;

ñ iseven : Nat → Bool

iseven 7;

ñ false : Bool

The intuition is that the higher-order function ff passed to fix is a generator

for the iseven function: if ff is applied to a function ie that approximates

the desired behavior of iseven up to some number n (that is, a function that

returns correct results on inputs less than or equal to n), then it returns a

better approximation to iseven—a function that returns correct results for

inputs up to n + 2. Applying fix to this generator returns its fixed point—a

function that gives the desired behavior for all inputs n.

However, there is one important difference from the untyped setting: fix

itself cannot be defined in the simply typed lambda-calculus. Indeed, we will

see in Chapter 12 that no expression that can lead to non-terminating compu-

tations can be typed using only simple types.8 So, instead of defining fix as

a term in the language, we simply add it as a new primitive, with evaluation

rules mimicking the behavior of the untyped fix combinator and a typing

rule that captures its intended uses. These rules are written out in Figure

11-12. (The letrec abbreviation will be discussed below.)

The simply typed lambda-calculus with numbers and fix has long been a

favorite experimental subject for programming language researchers, since

it is the simplest language in which a range of subtle semantic phenomena

such as full abstraction (Plotkin, 1977, Hyland and Ong, 2000, Abramsky, Ja-

gadeesan, and Malacaria, 2000) arise. It is often called PCF .

8. In later chapters—Chapter 13 and Chapter 20—we will see some extensions of simple types

that recover the power to define fix within the system.

144 11 Simple Extensions

→ fix Extends λ→ (9-1)

New syntactic forms

t ::= … terms:

fix t fixed point of t

New evaluation rules t -→ t′

fix (λx:T1.t2)

-→ [x, (fix (λx:T1.t2))]t2
(E-FixBeta)

t1 -→ t
′
1

fix t1 -→ fix t
′
1

(E-Fix)

New typing rules Γ ` t : T

Γ ` t1 : T1→T1

Γ ` fix t1 : T1
(T-Fix)

New derived forms

letrec x :T1 =t1 in t2
def
= let x = fix (λx :T1 .t1) in t2

Figure 11-12: General recursion

11.11.1 Exercise [««]: Define equal, plus, times, and factorial using fix. �

The fix construct is typically used to build functions (as fixed points of

functions from functions to functions), but it is worth noticing that the type

T in rule T-Fix is not restricted to function types. This extra power is some-

times handy. For example, it allows us to define a record of mutually recursive

functions as the fixed point of a function on records (of functions). The fol-

lowing implementation of iseven uses an auxiliary function isodd; the two

functions are defined as fields of a record, where the definition of this record

is abstracted on a record ieio whose components are used to make recursive

calls from the bodies of the iseven and isodd fields.

ff = λieio:{iseven:Nat→Bool, isodd:Nat→Bool}.

{iseven = λx:Nat.

if iszero x then true

else ieio.isodd (pred x),

isodd = λx:Nat.

if iszero x then false

else ieio.iseven (pred x)};

ñ ff : {iseven:Nat→Bool,isodd:Nat→Bool} →

{iseven:Nat→Bool, isodd:Nat→Bool}

Forming the fixed point of the function ff gives us a record of two functions

r = fix ff;

ñ r : {iseven:Nat→Bool, isodd:Nat→Bool}

11.11 General Recursion 145

and projecting the first of these gives us the iseven function itself:

iseven = r.iseven;

ñ iseven : Nat → Bool

iseven 7;

ñ false : Bool

The ability to form the fixed point of a function of type T→T for any T

has some surprising consequences. In particular, it implies that every type is

inhabited by some term. To see this, observe that, for every type T, we can

define a function divergeT as follows:

divergeT = λ_:Unit. fix (λx:T.x);

ñ divergeT : Unit → T

Whenever divergeT is applied to a unit argument, we get a non-terminating

evaluation sequence in which E-FixBeta is applied over and over, always

yielding the same term. That is, for every type T, the term divergeT unit

is an undefined element of T.

One final refinement that we may consider is introducing more convenient

concrete syntax for the common case where what we want to do is to bind a

variable to the result of a recursive definition. In most high-level languages,

the first definition of iseven above would be written something like this:

letrec iseven : Nat→Bool =

λx:Nat.

if iszero x then true

else if iszero (pred x) then false

else iseven (pred (pred x))

in

iseven 7;

ñ false : Bool

The recursive binding construct letrec is easily defined as a derived form:

letrec x:T1=t1 in t2
def
= let x = fix (λx:T1.t1) in t2

11.11.2 Exercise [«]: Rewrite your definitions of plus, times, and factorial from

Exercise 11.11.1 using letrec instead of fix. �

Further information on fixed point operators can be found in Klop (1980)

and Winskel (1993).

146 11 Simple Extensions

11.12 Lists

The typing features we have seen can be classified into base types like Bool

and Unit, and type constructors like → and × that build new types from

old ones. Another useful type constructor is List. For every type T, the type

List T describes finite-length lists whose elements are drawn from T.

Figure 11-13 summarizes the syntax, semantics, and typing rules for lists.

Except for syntactic differences (List T instead of T list, etc.) and the ex-

plicit type annotations on all the syntactic forms in our presentation,9 these

lists are essentially identical to those found in ML and other functional lan-

guages. The empty list (with elements of type T) is written nil[T]. The list

formed by adding a new element t1 (of type T) to the front of a list t2 is writ-

ten cons[T] t1 t2. The head and tail of a list t are written head[T] t and

tail[T] t. The boolean predicate isnil[T] t yields true iff t is empty.10

11.12.1 Exercise [«««]: Verify that the progress and preservation theorems hold for

the simply typed lambda-calculus with booleans and lists. �

11.12.2 Exercise [««]: The presentation of lists here includes many type annotations

that are not really needed, in the sense that the typing rules can easily derive

the annotations from context. Can all the type annotations be deleted? �

9. Most of these explicit annotations could actually be omitted (Exercise [«,3]: which cannot);

they are retained here to ease comparison with the encoding of lists in §23.4.

10. We adopt the “head/tail/isnil presentation” of lists here for simplicity. From the per-

spective of language design, it is arguably better to treat lists as a datatype and use case

expressions for destructing them, since more programming errors can be caught as type errors

this way.

11.12 Lists 147

→ B List Extends λ→ (9-1) with booleans (8-1)

New syntactic forms

t ::= … terms:

nil[T] empty list

cons[T] t t list constructor

isnil[T] t test for empty list

head[T] t head of a list

tail[T] t tail of a list

v ::= … values:

nil[T] empty list

cons[T] v v list constructor

T ::= … types:

List T type of lists

New evaluation rules t -→ t′

t1 -→ t
′
1

cons[T] t1 t2 -→ cons[T] t
′
1
t2

(E-Cons1)

t2 -→ t
′
2

cons[T] v1 t2 -→ cons[T] v1 t
′
2

(E-Cons2)

isnil[S] (nil[T]) -→ true (E-IsnilNil)

isnil[S] (cons[T] v1 v2) -→ false

(E-IsnilCons)

t1 -→ t
′
1

isnil[T] t1 -→ isnil[T] t
′
1

(E-Isnil)

head[S] (cons[T] v1 v2) -→ v1

(E-HeadCons)

t1 -→ t
′
1

head[T] t1 -→ head[T] t
′
1

(E-Head)

tail[S] (cons[T] v1 v2) -→ v2

(E-TailCons)

t1 -→ t
′
1

tail[T] t1 -→ tail[T] t
′
1

(E-Tail)

New typing rules Γ ` t : T

Γ ` nil [T1] : List T1 (T-Nil)

Γ ` t1 : T1 Γ ` t2 : List T1

Γ ` cons[T1] t1 t2 : List T1
(T-Cons)

Γ ` t1 : List T11

Γ ` isnil[T11] t1 : Bool
(T-Isnil)

Γ ` t1 : List T11

Γ ` head[T11] t1 : T11
(T-Head)

Γ ` t1 : List T11

Γ ` tail[T11] t1 : List T11
(T-Tail)

Figure 11-13: Lists

12 Normalization

In this chapter, we consider another fundamental theoretical property of the

pure 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 normaliza-

tion 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 (§11.11) or recursive types (Chapter 20)

that can be used to write nonterminating programs. However, the issue of

normalization will reappear at the level of types when we discuss the metathe-

ory of System Fω in §30-3: 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.

Some readers may prefer to skip this chapter on a first reading; doing so

will not cause any problems in later chapters. (A full table of chapter depen-

dencies appears on page xvi.)

12.1 Normalization for Simple Types

The calculus we shall consider here is the simply typed lambda-calculus over

a single base type A. Normalization for this calculus is not entirely trivial to

prove, since each reduction of a term can duplicate redexes in subterms.

The language studied in this chapter is the simply typed lambda-calculus (Figure 9-1) with a

single base type A (11-1).

150 12 Normalization

12.1.1 Exercise [«]: Where do we fail if we attempt to prove normalization by a

straightforward induction on the size of a well-typed term? �

The key issue here (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 RT of closed terms of type T. We regard these sets as predicates

and write RT(t) for t ∈ RT.
1

12.1.2 Definition:

• RA(t) iff t halts.

• RT1→T2(t) iff t halts and, whenever RT1(s), we have RT2(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 func-

tional 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 Definition 12.1.2 is characteristic of the logical relations proof

technique. (Since we are just dealing with unary relations here, we should

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 prop-

erty 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.

We use this definition to carry out the proof of normalization in two steps.

First, we observe that every element of every set RT is normalizable. Then we

show that every well-typed term of type T is an element of RT.

The first step is immediate from the definition of RT:

12.1.3 Lemma: If RT(t), then t halts. �

The second step is broken into two lemmas. First, we remark that member-

ship in RT is invariant under evaluation.

1. The sets RT are sometimes called saturated sets or reducibility candidates.

12.1 Normalization for Simple Types 151

12.1.4 Lemma: If t : T and t -→ t′, then RT(t) iff RT(t
′). �

Proof: By induction on the structure of the type T. Note, first, that it is clear

that t halts iff t′ does. If T = A, there is nothing more to show. Suppose,

on the other hand, that T = T1→T2 for some T1 and T2. For the “only if”

direction ( =⇒) suppose that RT(t) and that RT1(s) for some arbitrary s : T1.

By definition we have RT2 (t s). But t s -→ t
′ s, from which the induction

hypothesis for type T2 gives us RT2 (t
′ s). Since this holds for an arbitrary s,

the definition of RT gives us RT(t
′). The argument for the “if” direction (⇐= )

is analogous. �

Next, we want to show that every term of type T belongs to RT. 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 typ-

ing derivations!). The only technical difficulty here is in dealing with the λ-

abstraction case. Since we are arguing by induction, the demonstration that

a term λx:T1.t2 belongs to RT1→T2 should involve applying the induction hy-

pothesis to show that t2 belongs to RT2 . But RT2 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.

12.1.5 Lemma: If x1:T1, . . . , xn:Tn ` t : T and v1 . . . ,vn are closed values of types

T1…Tn with RTi (vi ) for each i, then RT([x1 , v1] · · · [xn , vn]t). �

Proof: By induction on a derivation of x1:T1, . . . , xn:Tn ` t : T. (The most

interesting case is the one for abstraction.)

Case T-Var: t = xi T = Ti

Immediate.

Case T-Abs: t = λx:S1.s2 x1:T1, . . . , xn:Tn, x:S1 ` s2 : S2
T = S1→S2

Obviously, [x1 , v1] · · · [xn , vn]t evaluates to a value, since it is a value

already. What remains to show is that RS2(([x1 , v1] · · · [xn , vn]t) s) for

any s : S1 such that RS1 (s). So suppose s is such a term. By Lemma 12.1.3,

we have s -→
∗

v for some v. By Lemma 12.1.4, RS1(v). Now, by the induction

hypothesis, RS2([x1 , v1] · · · [xn , vn][x, v]s2). But

(λx:S1. [x1 , v1] · · · [xn , vn]s2) s

-→
∗

[x1 , v1] · · · [xn , vn][x, v]s2,

from which Lemma 12.1.4 gives us

RS2((λx:S1. [x1 , v1] · · · [xn , vn]s2) s),

152 12 Normalization

that is, RS2((([x1 , v1] · · · [xn , vn](λx:S1. s2)) s). Since s was chosen

arbitrarily, the definition of RS1→S2 gives us

RS1→S2([x1 , v1] · · · [xn , vn](λx:S1. s2)).

Case T-App: t = t1 t2
x1:T1, . . . , xn:Tn ` t1 : T11→T12
x1:T1, . . . , xn:Tn ` t2 : T11
T = T12

The induction hypothesis gives us RT11→T12([x1 , v1] · · · [xn , vn]t1) and

RT11([x1 , v1] · · · [xn , vn]t2). By the definition of RT11→T12 ,

RT12(([x1 , v1] · · · [xn , vn]t1) ([x1 , v1] · · · [xn , vn]t2)),

i.e., RT12([x1 , v1] · · · [xn , vn](t1 t2)),. �

We now obtain the normalization property as a corollary, simply by tak-

ing the term t to be closed in Lemma 12.1.5 and then recalling that all the

elements of RT are normalizing, for every T.

12.1.6 Theorem [Normalization]: If ` t : T, then t is normalizable. �

Proof: RT(t) by Lemma 12.1.5; t is therefore normalizable by Lemma 12.1.3. �

12.1.7 Exercise [Recommended, «««]: Extend the proof technique from this chap-

ter to show that the simply typed lambda-calculus remains normalizing when

extended with booleans (Figure 3-1) and products (Figure 11-5). �

12.2 Notes

Normalization properties are most commonly formulated in the theoreti-

cal literature as strong normalization for calculi with full (non-deterministic)

beta-reduction. The standard proof method was invented by Tait (1967), gen-

eralized to System F (cf. Chapter 23) by Girard (1972, 1989), and later sim-

plified by Tait (1975). The presentation used here is an adaptation of Tait’s

method to the call-by-value setting, due to Martin Hofmann (private commu-

nication). The classical references on the logical relations proof technique are

Howard (1973), Tait (1967), Friedman (1975), Plotkin (1973, 1980), and Stat-

man (1982, 1985a, 1985b). It is also discussed in many texts on semantics,

for example those by Mitchell (1996) and Gunter (1992).

Tait’s strong normalization proof corresponds exactly to an algorithm for

evaluating simply typed terms, known as normalization by evaluation or type-

directed partial evaluation (Berger, 1993; Danvy, 1998); also see Berger and

Schwichtenberg (1991), Filinski (1999), Filinski (2001), Reynolds (1998a).

13 References

So far, we have considered a variety of pure language features, including func-

tional 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 fea-

tures 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 net-

work connections, make non-local transfers of control via exceptions, jumps,

or continuations, engage in inter-process synchronization and communica-

tion, and so on. In the literature on programming languages, such “side ef-

fects” 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 straightfor-

ward to define; the most interesting part is the refinement we need to make to

the statement of the type preservation theorem (13.5.3). We consider another

kind of effect—exceptions and non-local transfer of control—in Chapter 14.

13.1 Introduction

Nearly every programming language1 provides some form of assignment op-

eration that changes the contents of a previously allocated piece of storage.

The system studied in this chapter is the simply typed lambda-calculus with Unit and refer-

ences (Figure 13-1). The associated OCaml implementation is fullref.

1. Even “purely functional” languages such as Haskell, via extensions such as monads.

154 13 References

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 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, includ-

ing Java—every variable name refers to a mutable cell, and the operation of

dereferencing a variable to obtain its current contents is implicit.2

For purposes of formal study, it is useful to keep these mechanisms sepa-

rate;3 our development in this chapter will closely follow ML’s model. Apply-

ing the lessons learned here to C-like languages is a straightforward matter of

collapsing some distinctions and rendering certain operations such as deref-

erencing implicit instead of explicit.

Basics

The basic operations on references are allocation, dereferencing, and assign-

ment. To allocate a reference, we use the ref operator, providing an initial

value for the new cell.

r = ref 5;

ñ r : Ref Nat

The response from the typechecker indicates that the value of r is a reference

to a cell that will always contain a number. To read the current value of this

cell, we use the dereferencing operator !.

!r;

ñ 5 : Nat

To change the value stored in the cell, we use the assignment operator.

2. Strictly speaking, most variables of type T in C or Java should actually be thought of as

pointers to cells holding values of type Option(T), reflecting the fact that the contents of a

variable can be either a proper value or the special value null.

3. There are also good arguments that this separation is desirable from the perspective of

language design. Making the use of mutable cells an explicit choice rather than the default

encourages a mostly functional programming style where references are used sparingly; this

practice tends to make programs significantly easier to write, maintain, and reason about,

especially in the presence of features like concurrency.

13.1 Introduction 155

r := 7;

ñ unit : Unit

(The result the assignment is the trivial unit value; see §11.2.) If we derefer-

ence r again, we see the updated value.

!r;

ñ 7 : Nat

Side Effects and Sequencing

The fact that the result of an assignment expression is the trivial value unit

fits nicely with the sequencing notation defined in §11.3, allowing us to write

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

ñ 8 : Nat

instead of the equivalent, but more cumbersome,

(λ_:Unit. !r) (r := succ(!r));

ñ 9 : Nat

to evaluate two expressions in order and return the value of the second. Re-

stricting 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);

ñ 13 : Nat

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.

13

r =

156 13 References

If we make a copy of r, for example by binding its value to another variable

s,

s = r;

ñ s : Ref Nat

what gets copied is only the reference (the arrow in the diagram), not the cell:

13

s =r =

We can verify this by assigning a new value into s

s := 82;

ñ unit : Unit

and reading it out via r:

!r;

ñ 82 : Nat

The references r and s are said to be aliases for the same cell.

13.1.1 Exercise [«]: Draw a similar diagram showing the effects of evaluating the

expressions a = {ref 0, ref 0} and b = (λx:Ref Nat. {x,x}) (ref 0). �

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:

c = ref 0;

ñ c : Ref Nat

13.1 Introduction 157

incc = λx:Unit. (c := succ (!c); !c);

ñ incc : Unit → Nat

decc = λx:Unit. (c := pred (!c); !c);

ñ decc : Unit → Nat

Calling incc

incc unit;

ñ 1 : Nat

results in changes to c that can be observed by calling decc:

decc unit;

ñ 0 : Nat

If we package incc and decc together into a record

o = {i = incc, d = decc};

ñ o : {i:Unit→Nat, d:Unit→Nat}

then we can pass this whole structure around as a unit and use its compo-

nents to perform incrementing and decrementing operations on the shared

piece of state in c. In effect, we have constructed a simple kind of object . This

idea is developed in detail in Chapter 18.

References to Compound Types

A reference cell need not contain just a number: the primitives above al-

low 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) im-

plementation of arrays of numbers, as follows. Write NatArray for the type

Ref (Nat→Nat).

NatArray = Ref (Nat→Nat);

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);

ñ newarray : Unit → NatArray

158 13 References

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

index.

lookup = λa:NatArray. λn:Nat. (!a) n;
ñ lookup : NatArray → Nat → Nat

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);
ñ update : NatArray → Nat → Nat → Unit

13.1.2 Exercise [««]: 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? �

References to values containing other references can also be very useful,

allowing us to define data structures such as mutable lists and trees. (Such

structures generally also involve recursive types, which we introduce in Chap-

ter 20.)

Garbage Collection

A last issue that we should mention before we move on formalizing refer-

ences is storage deallocation. 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.

13.1.3 Exercise [««]: Show how this can lead to a violation of type safety. �

13.2 Typing 159

13.2 Typing

The typing rules for ref, :=, and ! follow straightforwardly from the behav-

iors we have given them.

Γ ` t1 : T1

Γ ` ref t1 : Ref T1
(T-Ref)

Γ ` t1 : Ref T1

Γ ` !t1 : T1
(T-Deref)

Γ ` t1 : Ref T1 Γ ` t2 : T1

Γ ` t1:=t2 : Unit
(T-Assign)

13.3 Evaluation

A more subtle aspect of the treatment of references appears when we con-

sider 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 es-

sentially 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 ref-

erence 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. Furthermore, we can abstract away from the fact that references (i.e.,

indexes into this array) are numbers. We take references to be elements of

some uninterpreted set L of store locations, and take the store to be simply

a partial function from locations l to values. We use the metavariable µ to

range over stores. A reference, then, is a location—an abstract index into the

store. We’ll use the word location instead of reference or pointer from now on

to emphasize this abstract quality.4

4. Treating locations abstractly in this way will prevent us from modeling the pointer arith-

160 13 References

Next, we need to extend our operational semantics to take stores into ac-

count. 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 | µ -→ t′ | µ′, where µ and µ′ are the starting and ending

states of the store. In effect, we have enriched our notion of abstract ma-

chines, so that a machine state is not just a program counter (represented as

a term), but a program counter plus the current contents of the store.

To carry through this change, we first need to augment all of our existing

evaluation rules with stores:

(λx:T11.t12) v2| µ -→ [x, v2]t12| µ (E-AppAbs)

t1| µ -→ t
′
1
| µ′

t1 t2| µ -→ t
′
1
t2| µ

′
(E-App1)

t2| µ -→ t
′
2
| µ′

v1 t2| µ -→ v1 t
′
2
| µ′

(E-App2)

Note that the first rule here returns the store µ unchanged: function applica-

tion, in itself, has no side effects. The other two rules simply propagate side

effects from premise to conclusion.

Next, we make a small addition to the syntax of our terms. The result of

evaluating a ref expression will be a fresh location, so we need to include

locations in the set of things that can be results of evaluation—i.e., in the set

of values:

v ::= values:

λx:T.t abstraction value

unit unit value

l store location

Since all values are also terms, this means that the set of terms should include

locations.

metic 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.

13.3 Evaluation 161

t ::= terms:

x variable

λx:T.t abstraction

t t application

unit constant unit

ref t reference creation

!t dereference

t:=t assignment

l store location

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 effect,

the term language in this chapter should be thought of as formalizing an

intermediate language, some of whose features are not made available to

programmers directly.

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 | µ -→ t
′
1
| µ′

!t1 | µ -→ !t
′
1
| µ′

(E-Deref)

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. The evaluation rules

simply get stuck in this case. The type safety properties in §13.5 assure us

that well-typed terms will never misbehave in this way.

µ(l) = v

!l | µ -→ v | µ
(E-DerefLoc)

Next, to evaluate an assignment expression t1:=t2, we must first evaluate

t1 until it becomes a value (i.e., a location),

t1 | µ -→ t
′
1
| µ′

t1:=t2 | µ -→ t
′
1
:=t2 | µ

′
(E-Assign1)

and then evaluate t2 until it becomes a value (of any sort):

t2 | µ -→ t
′
2
| µ′

v1:=t2 | µ -→ v1:=t
′
2
| µ′

(E-Assign2)

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:=v2 | µ -→ unit | [l , v2]µ (E-Assign)

162 13 References

(The notation [l , v2]µ here means “the store that maps l to v2 and maps

all other locations to the same thing as µ.” 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 | µ -→ t
′
1
| µ′

ref t1 | µ -→ ref t
′
1
| µ′

(E-Ref)

Then, to evaluate the ref itself, we choose a fresh location l (i.e., a location

that is not already part of the domain of µ) and yield a new store that extends

µ with the new binding l , v1.

l ∉ dom(µ)

ref v1 | µ -→ l | (µ, l , v1)
(E-RefV)

The term resulting from this step is the name l of the newly allocated loca-

tion.

Note that these evaluation rules do not perform any kind of garbage collec-

tion: 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 will sometimes run out

of memory where a more sophisticated evaluator would be able to continue

by reusing locations whose contents have become garbage.

13.3.1 Exercise [«««]: How might our evaluation rules be refined to model garbage

collection? What theorem would we then need to prove, to argue that this

refinement is correct? �

13.4 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 re-

sult depends on the contents of the store that we start with. For example, if

we evaluate the term !l2 in the store (l1 , unit, l2 , unit), the result is

unit; if we evaluate the same term in the store (l1 , unit, l2 , λx:Unit.x),

the result is λx:Unit.x. With respect to the former store, the location l2 has

type Unit, and with respect to the latter it has type Unit→Unit. This obser-

vation leads us immediately to a first attempt at a typing rule for locations:

13.4 Store Typings 163

Γ ` µ(l) : T1

Γ ` 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: Γ | µ ` t : T. Our rule for typing references now

has the form

Γ | µ ` µ(l) : T1

Γ | µ ` 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 typ-

ing derivation for t. Worse, if v itself contains locations, then we will have

to recalculate their types each time they appear. For example, if the store

contains

(l1 , λx:Nat. 999,

l2 , λx:Nat. (!l1) x,

l3 , λx:Nat. (!l2) x,

l4 , λx:Nat. (!l3) x,

l5 , λx:Nat. (!l4) x),

then calculating the type of l5 involves calculating those of l4, l3, l2, and l1.

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 l2 with respect to the store

(l1 , λx:Nat. (!l2) x,

l2 , λx:Nat. (!l1) x),

since calculating a type for l2 requires finding the type of l1, which in turn

involves l1, etc. Cyclic reference structures do arise in practice (e.g., they can

164 13 References

be used for building doubly linked lists), and we would like our type system

to be able to deal with them.

13.4.1 Exercise [«]: 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. We’ll use the metavariable Σ to range over such

functions.

Suppose we are given a store typing Σ describing the store µ in which some

term t will be evaluated. Then we can use Σ to calculate the type of the result

of t without ever looking directly at µ. For example, if Σ is (l1 , Unit, l2 ,

Unit→Unit), then we may immediately infer that !l2 has type Unit→Unit.

More generally, the typing rule for locations can be reformulated in terms of

store typings like this:

Σ(l) = T1

Γ | Σ ` l : Ref T1
(T-Loc)

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.

Of course, these typing rules will accurately predict the results of evalua-

tion only if the concrete store used during evaluation actually conforms to the

store typing that we assume for purposes of typechecking. This proviso ex-

actly parallels the situation with free variables in all the calculi we have seen

up to this point: the substitution lemma (9.3.8) promises us that, if Γ ` t : T,

then we can replace the free variables in t with values of the types listed in

Γ to obtain a closed term of type T, which, by the type preservation theorem

(9.3.9) will evaluate to a final result of type T if it yields any result at all. We

will see in §13.5 how to formalize an analogous intuition for stores and store

typings.

Finally, note that, for purposes of typechecking the terms that program-

mers actually write, we do not need to do anything tricky to guess what store

typing we should use. As we remarked above, concrete location constants

13.5 Safety 165

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 (13.5.3).

Now that we have dealt with locations, the typing rules for the other new

syntactic forms are quite straightforward. When we create a reference to a

value of type T1, the reference itself has type Ref T1.

Γ | Σ ` t1 : T1

Γ | Σ ` ref t1 : Ref T1
(T-Ref)

Notice that we do not need to extend the store typing here, since the name of

the new location will not be determined until run time, while Σ records only

the association between already-allocated storage cells and their types.

Conversely, if t1 evaluates to a location of type Ref T11, then dereferencing

t1 is guaranteed to yield a value of type T11.

Γ | Σ ` t1 : Ref T11

Γ | Σ ` !t1 : T11
(T-Deref)

Finally, if t1 denotes a cell of type Ref T11, then we can store t2 into this

cell as long as the type of t2 is also T11:

Γ | Σ ` t1 : Ref T11 Γ | Σ ` t2 : T11

Γ | Σ ` t1:=t2 : Unit
(T-Assign)

Figure 13-1 summarizes the typing rules (and the syntax and evaluation

rules, for easy reference) for the simply typed lambda-calculus with refer-

ences.

13.5 Safety

Our final job in this chapter is to check that standard type safety proper-

ties continue to hold for the calculus with references. The progress theorem

(“well-typed terms are not stuck”) can be stated and proved almost as before

(cf. 13.5.7); we just need to add a few straightforward cases to the proof,

dealing with the new constructs. The preservation theorem is a bit more in-

teresting, so let’s look at it first.

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

166 13 References

→ Unit Ref Extends λ→ with Unit (9-1 and 11-2)

Syntax

t ::= terms:

x variable

λx:T.t abstraction

t t application

unit constant unit

ref t reference creation

!t dereference

t:=t assignment

l store location

v ::= values:

λx:T.t abstraction value

unit constant unit

l store location

T ::= types:

T→T type of functions

Unit unit type

Ref T type of reference cells

Γ ::= contexts:

∅ empty context

Γ , x:T term variable binding

µ ::= stores:

∅ empty store

µ, l = v location binding

Σ ::= store typings:

∅ empty store typing

Σ, l:T location typing

Evaluation t | µ -→ t′ | µ′

t1 | µ -→ t
′
1
| µ′

t1 t2 | µ -→ t
′
1
t2 | µ

′
(E-App1)

t2 | µ -→ t
′
2
| µ′

v1 t2 | µ -→ v1 t
′
2
| µ′

(E-App2)

(λx:T11.t12) v2 | µ -→ [x, v2]t12 | µ

(E-AppAbs)

l ∉ dom(µ)

ref v1 | µ -→ l | (µ, l , v1)
(E-RefV)

t1 | µ -→ t
′
1
| µ′

ref t1 | µ -→ ref t
′
1
| µ′

(E-Ref)

µ(l) = v

!l | µ -→ v | µ
(E-DerefLoc)

t1 | µ -→ t
′
1
| µ′

!t1 | µ -→ !t
′
1
| µ′

(E-Deref)

l:=v2 | µ -→ unit | [l , v2]µ (E-Assign)

t1 | µ -→ t
′
1
| µ′

t1:=t2 | µ -→ t
′
1
:=t2 | µ

′
(E-Assign1)

t2 | µ -→ t
′
2
| µ′

v1:=t2 | µ -→ v1:=t
′
2
| µ′

(E-Assign2)

continued . . .

Figure 13-1: References

13.5 Safety 167

Typing Γ | Σ ` t : T

x:T ∈ Γ

Γ | Σ ` x : T
(T-Var)

Γ , x:T1 | Σ ` t2 : T2

Γ | Σ ` λx:T1.t2 : T1→T2
(T-Abs)

Γ | Σ ` t1 : T11→T12 Γ | Σ ` t2 : T11

Γ | Σ ` t1 t2 : T12
(T-App)

Γ | Σ ` unit : Unit (T-Unit)

Σ(l) = T1

Γ | Σ ` l : Ref T1
(T-Loc)

Γ | Σ ` t1 : T1

Γ | Σ ` ref t1 : Ref T1
(T-Ref)

Γ | Σ ` t1 : Ref T11

Γ | Σ ` !t1 : T11
(T-Deref)

Γ | Σ ` t1 : Ref T11 Γ | Σ ` t2 : T11

Γ | Σ ` t1:=t2 : Unit

(T-Assign)

Figure 13-1: References (continued)

cannot just add stores and store typings without saying anything about how

they are related.

If Γ | Σ ` t : T and t | µ -→ t′ | µ′, then Γ | Σ ` t′ : T. (Wrong!)

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. The following requirement ex-

presses the constraint we need.

13.5.1 Definition: A store µ is said to be well typed with respect to a typing context

Γ and a store typing Σ, written Γ | Σ ` µ, if dom(µ) = dom(Σ) and Γ | Σ `

µ(l) : Σ(l) for every l ∈ dom(µ). �

Intuitively, a store µ is consistent with a store typing Σ if every value in the

store has the type predicted by the store typing.

13.5.2 Exercise [««]: Can you find a context Γ , a store µ, and two different store

typings Σ1 and Σ2 such that both Γ | Σ1 ` µ and Γ | Σ2 ` µ? �

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

If

Γ | Σ ` t : T

t | µ -→ t′ | µ′

Γ | Σ ` µ

168 13 References

then Γ | Σ ` t′ : T. (Less wrong.)

This statement is fine for all of the evaluation rules except the allocation rule

E-RefV. 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 µ′

includes a binding for a fresh location l, then l cannot be in the domain of

Σ, and it will not be the case that t′ (which definitely mentions l) is typable

under Σ.

Evidently, since the store can increase in size during evaluation, we need

to allow the store typing to grow as well. This leads us to the final (correct)

statement of the type preservation property:

13.5.3 Theorem [Preservation]: If

Γ | Σ ` t : T

Γ | Σ ` µ

t | µ -→ t′ | µ′

then, for some Σ′ ⊇ Σ,

Γ | Σ′ ` t′ : T

Γ | Σ′ ` µ′. �

Note that the preservation theorem merely asserts that there is some store

typing Σ′ ⊇ Σ (i.e., agreeing with Σ on the values of all the old locations)

such that the new term t′ is well typed with respect to Σ′; it does not tell

us exactly what Σ′ is. It is intuitively clear, of course, that Σ′ is either Σ or

else it is exactly (µ, l , T1), where l is a newly allocated location (the new

element of the domain of µ′) and T1 is the type of the initial value bound to l

in the extended store (µ, l , 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 ev-

ery 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.”

To prove preservation, we need a few technical lemmas. The first is an easy

extension of the standard substitution lemma (9.3.8).

13.5.4 Lemma [Substitution]: If Γ , x:S | Σ ` t : T and Γ | Σ ` s : S, then Γ | Σ `

[x, s]t : T. �

Proof: Just like Lemma 9.3.8. �

13.5 Safety 169

The next states 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.

13.5.5 Lemma: If

Γ | Σ ` µ

Σ(l) = T

Γ | Σ ` v : T

then Γ | Σ ` [l , v]µ. �

Proof: Immediate from the definition of Γ | Σ ` µ. �

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.

13.5.6 Lemma: If Γ | Σ ` t : T and Σ′ ⊇ Σ, then Γ | Σ′ ` t : T. �

Proof: Easy induction. �

Now we can prove the main preservation theorem.

Proof of 13.5.3: Straightforward induction on evaluation derivations, using

the lemmas above and the inversion property of the typing rules (a straight-

forward extension of 9.3.1). �

The statement of the progress theorem (9.3.5) must also be extended to

take stores and store typings into account:

13.5.7 Theorem [Progress]: Suppose t is a closed, well-typed term (that is,∅ | Σ `

t : T for some T and Σ). Then either t is a value or else, for any store µ such

that ∅ | Σ ` µ, there is some term t′ and store µ′ with t | µ -→ t′ | µ′. �

Proof: Straightforward induction on typing derivations, following the pat-

tern of 9.3.5. (The canonical forms lemma, 9.3.4, needs two additional cases

stating that all values of type Ref T are locations and similarly for Unit.) �

13.5.8 Exercise [Recommended, «««]: Is the evaluation relation in this chapter nor-

malizing on well-typed terms? If so, prove it. If not, write a well-typed factorial

function in the present calculus (extended with numbers and booleans). �

170 13 References

13.6 Notes

The presentation in this chapter is adapted from a treatment by Harper (1994,

1996). An account in a similar style is given by Wright and Felleisen (1994).

The combination of references (or other computational effects) with ML-

style polymorphic type inference raises some quite subtle problems (cf. §22.7)

and has received a good deal of attention in the research literature. See Tofte

(1990), Hoang et al. (1993), Jouvelot and Gifford (1991), Talpin and Jouvelot

(1992), Leroy and Weis (1991), Wright (1992), Harper (1994, 1996), and the

references cited there.

Static prediction of possible aliasing is a long-standing problem both in

compiler implementation (where it is called alias analysis) and in program-

ming language theory. An influential early attempt by Reynolds (1978, 1989)

coined the term syntactic control of interference. These ideas have recently

seen a burst of new activity—see O’Hearn et al. (1995) and Smith et al. (2000).

More general reasoning techniques for aliasing are discussed in Reynolds

(1981) and Ishtiaq and O’Hearn (2001) and other references cited there.

A comprehensive discussion of garbage collection can be found in Jones

and Lins (1996). A more semantic treatment is given by Morrisett et al. (1995).

Find out the cause of this effect,

Or rather say, the cause of this defect,

For this effect defective comes by cause. —Hamlet II, ii, 101

The finger pointing at the moon is not the moon. —Buddhist saying

14 Exceptions

In Chapter 13 we saw how to extend the simple operational semantics of the

pure simply typed lambda-calculus with mutable references and considered

the effect of this extension on the typing rules and type safety proofs. In

this chapter, we treat another extension to our original computational model:

raising and handling exceptions.

Real-world programming is full of situations where a function needs to sig-

nal to its caller that it is unable to perform its task for some reason—because

some calculation would involve a division by zero or an arithmetic overflow,

a lookup key is missing from a dictionary, an array index went out of bounds,

a file could not be found or opened, some disastrous event occurred such as

the system running out of memory or the user killing the process, etc.

Some of these exceptional conditions can be signaled by making the func-

tion return a variant (or option), as we saw in §11.10. But in situations where

the exceptional conditions are truly exceptional, we may not want to force

every caller of our function to deal with the possibility that they may occur.

Instead, we may prefer that an exceptional condition causes a direct trans-

fer of control to an exception handler defined at some higher-level in the

program—or indeed (if the exceptional condition is rare enough or if there

is nothing that the caller can do anyway to recover from it) simply aborts

the program. We first consider the latter case (§14.1), where an exception is

a whole-program abort, then add a mechanism for trapping and recovering

from exceptions (§14.2), and finally refine both of these mechanisms to allow

extra programmer-specified data to be passed between exception sites and

handlers (§14.3).

The systems studied in this chapter are the simply typed lambda-calculus (Figure 9-1) ex-

tended with various primitives for exceptions and exception handling (Figures 14-1 and 14-2).

The OCaml implementation of the first extension is fullerror. The language with exceptions

carrying values (Figure 14-3) is not implemented.

172 14 Exceptions

→ error Extends λ→ (9-1)

New syntactic forms

t ::= … terms:

error run-time error

New evaluation rules t -→ t′

error t2 -→ error (E-AppErr1)

v1 error -→ error (E-AppErr2)

New typing rules Γ ` t : T

Γ ` error : T (T-Error)

Figure 14-1: Errors

14.1 Raising Exceptions

Let us start by enriching the simply typed lambda-calculus with the simplest

possible mechanism for signaling exceptions: a term error that, when evalu-

ated, completely aborts evaluation of the term in which it appears. Figure 14-1

details the needed extensions.

The main design decision in writing the rules for error is how to formalize

“abnormal termination” in our operational semantics. We adopt the simple

expedient of letting error itself be the result of a program that aborts. The

rules E-AppErr1 and E-AppErr2 capture this behavior. E-AppErr1 says that,

if we encounter the term error while trying to reduce the left-hand side of

an application to a value, we should immediately yield error as the result

of the application. Similarly, E-AppErr2 says that, if we encounter an error

while we are working on reducing the argument of an application to a value,

we should abandon work on the application and immediately yield error.

Observe that we have not included error in the syntax of values—only the

syntax of terms. This guarantees that there will never be an overlap between

the left-hand sides of the E-AppAbs and E-AppErr2 rules—i.e., there is no

ambiguity as to whether we should evaluate the term

(λx:Nat.0) error

by performing the application (yielding 0 as result) or aborting: only the latter

is possible. Similarly, the fact that we used the metavariable v1 (rather than

t1, ranging over arbitrary terms) in E-AppErr2 forces the evaluator to wait

until the left-hand side of an application is reduced to a value before aborting

14.2 Handling Exceptions 173

it, even if the right-hand side is error. Thus, a term like

(fix (λx:Nat.x)) error

will diverge instead of aborting. These conditions ensure that the evaluation

relation remains deterministic.

The typing rule T-Error is also interesting. Since we may want to raise an

exception in any context, the term error form is allowed to have any type

whatsoever. In

(λx:Bool.x) error;

it has type Bool. In

(λx:Bool.x) (error true);

it has type Bool→Bool.

This flexibility in error’s type raises some difficulties in implementing a

typechecking algorithm, since it breaks the property that every typable term

in the language has a unique type (Theorem 9.3.3). This can be dealt with in

various ways. In a language with subtyping, we can assign error the minimal

type Bot (see §15.4), which can be promoted to any other type as necessary.

In a language with parametric polymorphism (see Chapter 23), we can give

error the polymorphic type ∀X.X, which can be instantiated to any other

type. Both of these tricks allow infinitely many possible types for error to be

represented compactly by a single type.

14.1.1 Exercise [«]: Wouldn’t it be simpler just to require the programmer to an-

notate error with its intended type in each context where it is used? �

The type preservation property for the language with exceptions is the

same as always: if a term has type T and we let it evaluate one step, the

result still has type T. The progress property, however, needs to be refined a

little. In its original form, it said that a well-typed program must evaluate to

a value (or diverge). But now we have introduced a non-value normal form,

error, which can certainly be the result of evaluating a well-typed program.

We need to restate progress to allow for this.

14.1.2 Theorem [Progress]: Suppose t is a closed, well-typed normal form. Then

either t is a value or t = error. �

14.2 Handling Exceptions

The evaluation rules for error can be thought of as “unwinding the call

stack,” discarding pending function calls until the error has propagated all

174 14 Exceptions

→ error try Extends λ→ with errors (14-1)

New syntactic forms

t ::= … terms:

try t with t trap errors

New evaluation rules t -→ t′

try v1 with t2 -→ v1 (E-TryV)

try error with t2

-→ t2
(E-TryError)

t1 -→ t
′
1

try t1 with t2

-→ try t′
1
with t2

(E-Try)

New typing rules Γ ` t : T

Γ ` t1 : T Γ ` t2 : T

Γ ` try t1 with t2 : T
(T-Try)

Figure 14-2: Error handling

the way to the top level. In real implementations of languages with excep-

tions, this is exactly what happens: the call stack consists of a set of acti-

vation records, one for each active function call; raising an exception causes

activation records to be popped off the call stack until it becomes empty.

In most languages with exceptions, it is also possible to install exception

handlers in the call stack. When an exception is raised, activation records

are popped off the call stack until an exception handler is encountered, and

evaluation then proceeds with this handler. In other words, the exception

functions as a non-local transfer of control, whose target is the most recently

installed exception handler (i.e., the nearest one on the call stack).

Our formulation of exception handlers, summarized in Figure 14-2, is sim-

ilar to both ML and Java. The expression try t1 with t2 means “return the

result of evaluating t1, unless it aborts, in which case evaluate the handler t2

instead.” The evaluation rule E-TryV says that, when t1 has been reduced to

a value v1, we may throw away the try, since we know now that it will not

be needed. E-TryError, on the other hand, says that, if evaluating t1 results

in error, then we should replace the try with t2 and continue evaluating

from there. E-Try tells us that, until t1 has been reduced to either a value or

error, we should just keep working on it and leave t2 alone.

The typing rule for try follows directly from its operational semantics. The

result of the whole try can be either the result of the main body t1 or else

the result of the handler t2; we simply need to require that these have the

same type T, which is also the type of the try.

The type safety property and its proof remain essentially unchanged from

the previous section.

14.3 Exceptions Carrying Values 175

→ exceptions Extends λ→ (9-1)

New syntactic forms

t ::= … terms:

raise t raise exception

try t with t handle exceptions

New evaluation rules t -→ t′

(raise v11) t2 -→ raise v11 (E-AppRaise1)

v1 (raise v21) -→ raise v21 (E-AppRaise2)

t1 -→ t
′
1

raise t1 -→ raise t
′
1

(E-Raise)

raise (raise v11)

-→ raise v11
(E-RaiseRaise)

try v1 with t2 -→ v1 (E-TryV)

try raise v11 with t2

-→ t2 v11
(E-TryRaise)

t1 -→ t
′
1

try t1 with t2 -→ try t
′
1
with t2

(E-Try)

New typing rules Γ ` t : T

Γ ` t1 : Texn

Γ ` raise t1 : T
(T-Exn)

Γ ` t1 : T Γ ` t2 : Texn→T

Γ ` try t1 with t2 : T
(T-Try)

Figure 14-3: Exceptions carrying values

14.3 Exceptions Carrying Values

The mechanisms introduced in §14.1 and §14.2 allow a function to signal to

its caller that “something unusual happened.” It is generally useful to send

back some extra information about which unusual thing has happened, since

the action that the handler needs to take—either to recover and try again or

to present a comprehensible error message to the user—may depend on this

information.

Figure 14-3 shows how our basic exception handling constructs can be en-

riched so that each exception carries a value. The type of this value is written

Texn. For the moment, we leave the precise nature of this type open; below,

we discuss several alternatives.

The atomic term error is replaced by a term constructor raise t, where

t is the extra information that we want to pass to the exception handler. The

syntax of try remains the same, but the handler t2 in try t1 with t2 is now

interpreted as a function that takes the extra information as an argument.

The evaluation rule E-TryRaise implements this behavior, taking the extra

information carried by a raise from the body t1 and passing it to the handler

t2. E-AppRaise1 and E-AppRaise2 propagate exceptions through applications,

just like E-AppErr1 and E-AppErr2 in Figure 14-1. Note, however, that these

176 14 Exceptions

rules are allowed to propagate only exceptions whose extra information is

a value; if we attempt to evaluate a raise with extra information that itself

requires some evaluation, these rules will block, forcing us to use E-Raise to

evaluate the extra information first. E-RaiseRaise propagates exceptions that

may occur while we are evaluating the extra information that is to be sent

along in some other exception. E-TryV tells us that we can throw away a try

once its main body has reduced to a value, just as we did in §14.2. E-Try

directs the evaluator to work on the body of a try until it becomes either a

value or a raise.

The typing rules reflect these changes in behavior. In T-Raise we demand

that the extra information has type Texn; the whole raise can then be given

any type T that may be required by the context. In T-Try, we check that the

handler t2 is a function that, given the extra information of type Texn, yields

a result of the same type as t1.

Finally, let us consider some alternatives for the type Texn.

1. We can take Texn to be just Nat. This corresponds to the errno convention

used, for example, by Unix operating system functions: each system call

returns a numeric “error code,” with 0 signaling success and other values

reporting various exceptional conditions.

2. We can take Texn to be String, which avoids looking up error numbers

in tables and allows exception-raising sites to construct more descriptive

messages if they wish. The cost of this extra flexibility is that error han-

dlers may now have to parse these strings to find out what happened.

3. We can keep the ability to pass more informative exceptions while avoiding

string parsing if we define Texn to be a variant type:

Texn =

This scheme allows a handler to distinguish between kinds of exceptions

using a simple case expression. Also, different exceptions can carry differ-

ent types of additional information: exceptions like divideByZero need

no extra baggage, fileNotFound can carry a string indicating which file

was being opened when the error occurred, etc.

The problem with this alternative is that it is rather inflexible, demanding

that we fix in advance the complete set of exceptions that can be raised by

14.3 Exceptions Carrying Values 177

any program (i.e., the set of tags of the variant type Texn). This leaves no

room for programmers to declare application-specific exceptions.

4. The same idea can be refined to leave room for user-defined exceptions

by taking Texn to be an extensible variant type. ML adopts this idea, pro-

viding a single extensible variant type called exn.1 The ML declaration

exception l of T can be understood, in the present setting, as “make sure

that l is different from any tag already present in the variant type Texn,
2

and from now on let Texn be , where l1:T1 through

ln:tn were the possible variants before this declaration.”

The ML syntax for raising exceptions is raise l(t), where l is an excep-

tion tag defined in the current scope. This can be understood as a combi-

nation of the tagging operator and our simple raise:

raise l(t)
def
= raise ( as Texn)

Similarly, the ML try construct can be desugared using our simple try

plus a case.

try t with l(x) → h
def
= try t with

λe:Texn. case e of

⇒ h

| _ ⇒ raise e

The case checks whether the exception that has been raised is tagged with

l. If so, it binds the value carried by the exception to the variable x and

evaluates the handler h. If not, it falls through to the else clause, which

re-raises the exception. The exception will keep propagating (and perhaps

being caught and re-raised) until it either reaches a handler that wants to

deal with it, or else reaches the top level and aborts the whole program.

5. Java uses classes instead of extensible variants to support user-defined

exceptions. The language provides a built-in class Throwable; an instance

of Throwable or any of its subclasses can be used in a throw (same as our

raise) or try…catch (same as our try…with) statement. New excep-

tions can be declared simply by defining new subclasses of Throwable.

There is actually a close correspondence between this exception-handling

mechanism and that of ML. Roughly speaking, an exception object in Java

1. One can go further and provide extensible variant types as a general language feature, but

the designers of ML have chosen to simply treat exn as a special case.

2. Since the exception form is a binder, we can always ensure that l is different from the tags

already used in Texn by alpha-converting it if necessary.

178 14 Exceptions

is represented at run time by a tag indicating its class (which corresponds

directly to the extensible variant tag in ML) plus a record of instance vari-

ables (corresponding to the extra information labeled by this tag).

Java exceptions go a little further than ML in a couple of respects. One

is that there is a natural partial order on exception tags, generated by

the subclass ordering. A handler for the exception l will actually trap all

exceptions carrying an object of class l or any subclass of l. Another

is that Java distinguishes between exceptions (subclasses of the built-in

class Exception—a subclass of Throwable), which application programs

might want to catch and try to recover from, and errors (subclasses of

Error—also a subclass of Throwable), which indicate serious conditions

that should normally just terminate execution. The key difference between

the two lies in the typechecking rules, which demand that methods explic-

itly declare which exceptions (but not which errors) they might raise.

14.3.1 Exercise [«««]: The explanation of extensible variant types in alternative 4

above is rather informal. Show how to make it precise. �

14.3.2 Exercise [««««]: We noted above that Java exceptions (those that are sub-

classes of Exception) are a bit more strictly controlled than exceptions in

ML (or the ones we have defined here): every exception that might be raised

by a method must be declared in the method’s type. Extend your solution to

Exercise 14.3.1 so that the type of a function indicates not only its argument

and result types, but also the set of exceptions that it may raise. Prove that

your system is typesafe. �

14.3.3 Exercise [«««]: Many other control constructs can be formalized using tech-

niques similar to the ones we have seen in this chapter. Readers familiar

with the “call with current continuation” (call/cc) operator of Scheme (see

Clinger, Friedman, and Wand, 1985; Kelsey, Clinger, and Rees, 1998; Dybvig,

1996; Friedman, Wand, and Haynes, 2001) may enjoy trying to formulate typ-

ing rules based on a type Cont T of T-continuations—i.e., continuations that

expect an argument of type T. �

P a r t I I I

Subtyping

15 Subtyping

We have spent the last several chapters studying the typing behavior of a va-

riety of language features within the framework of the simply typed lambda-

calculus. This chapter addresses a more fundamental extension: subtyping

(sometimes called subtype polymorphism). Unlike the features we have stud-

ied up to now, which could be formulated more or less orthogonally to each

other, subtyping is a cross-cutting extension, interacting with most other lan-

guage features in non-trivial ways.

Subtyping is characteristically found in object-oriented languages and is

often considered an essential feature of the object-oriented style. We will ex-

plore this connection in detail in Chapter 18; for now, though, we present sub-

typing in a more economical setting with just functions and records, where

most of the interesting issues already appear. §15.5 discusses the combina-

tion of subtyping with some of the other features we have seen in previous

chapters. In the final section (15.6) we consider a more refined semantics

for subtyping, in which the use of suptyping corresponds to the insertion of

run-time coercions.

15.1 Subsumption

Without subtyping, the rules of the simply typed lambda-calculus can be

annoyingly rigid. The type system’s insistence that argument types exactly

match the domain types of functions will lead the typechecker to reject many

programs that, to the programmer, seem obviously well-behaved. For exam-

ple, recall the typing rule for function application:

Γ ` t1 : T11→T12 Γ ` t2 : T11

Γ ` t1 t2 : T12
(T-App)

The calculus studied in this chapter is λ<:, the simply typed lambda-calculus with subtyping (Figure 15-1) and records (15-3); the corresponding OCaml implementation is rcdsub. (Some of the examples also use numbers; fullsub is needed to check these.) 182 15 Subtyping According to this rule, the well-behaved term (λr:{x:Nat}. r.x) {x=0,y=1} is not typable, since the type of the argument is {x:Nat,y:Nat}, whereas the function accepts {x:Nat}. But, clearly, the function just requires that its argument is a record with a field x; it doesn’t care what other fields the argument may or may not have. Moreover, we can see this from the type of the function—we don’t need to look at its body to verify that it doesn’t use any fields besides x. It is always safe to pass an argument of type {x:Nat,y:Nat} to a function that expects type {x:Nat}. The goal of subtyping is to refine the typing rules so that they can accept terms like the one above. We accomplish this by formalizing the intuition that some types are more informative than others: we say that S is a subtype of T, written S <: T, to mean that any term of type S can safely be used in a context where a term of type T is expected. This view of subtyping is often called the principle of safe substitution. A simpler intuition is to read S <: T as “every value described by S is also described by T,” that is, “the elements of S are a subset of the elements of T.” We shall see in §15.6 that other, more refined, interpretations of subtyping are sometimes useful, but this subset semantics suffices for most purposes. The bridge between the typing relation and this subtype relation is pro- vided by adding a new typing rule—the so-called rule of subsumption: Γ ` t : S S <: T Γ ` t : T (T-Sub) This rule tells us that, if S <: T, then every element t of S is also an element of T. For example, if we define the subtype relation so that {x:Nat,y:Nat} <: {x:Nat}, then we can use rule T-Sub to derive ` {x=0,y=1} : {x:Nat}, which is what we need to make our motivating example typecheck. 15.2 The Subtype Relation The subtype relation is formalized as a collection of inference rules for de- riving statements of the form S <: T, pronounced “S is a subtype of T” (or “T is a supertype of S”). We consider each form of type (function types, record types, etc.) separately; for each one, we introduce one or more rules formal- izing situations when it is safe to allow elements of one type of this form to be used where another is expected. Before we get to the rules for particular type constructors, we make two general stipulations: first, that subtyping should be reflexive, S <: S (S-Refl) 15.2 The Subtype Relation 183 and second, that it should be transitive: S <: U U <: T S <: T (S-Trans) These rules follow directly from the intuition of safe substitution. Now, for record types, we have already seen that we want to consider the type S = {k1:S1...km:Sm} to be a subtype of T = {l1:T1...ln:Tn} if T has fewer fields than S. In particular, it is safe to “forget” some fields at the end of a record type. The so-called width subtyping rule captures this intuition: {li:Ti i∈1..n+k} <: {li:Ti i∈1..n} (S-RcdWidth) It may seem surprising that the “smaller” type—the subtype—is the one with more fields. The easiest way to understand this is to adopt a more liberal view of record types than we did in §11.8, regarding a record type {x:Nat} as describing “the set of all records with at least a field x of type Nat.” Val- ues like {x=3} and {x=5} are elements of this type, and so are values like {x=3,y=100} and {x=3,a=true,b=true}. Similarly, the record type {x:Nat, y:Nat} describes records with at least the fields x and y, both of type Nat. Values like {x=3,y=100} and {x=3,y=100,z=true} are members of this type, but {x=3} is not, and neither is {x=3,a=true,b=true}. Thus, the set of values belonging to the second type is a proper subset of the set belonging to the first type. A longer record constitutes a more demanding—i.e., more informative—specification, and so describes a smaller set of values. The width subtyping rule applies only to record types where the common fields are identical. It is also safe to allow the types of individual fields to vary, as long as the types of each corresponding field in the two records are in the subtype relation. The depth subtyping rule expresses this intuition: for each i Si <: Ti {li:Si i∈1..n} <: {li:Ti i∈1..n} (S-RcdDepth) The following subtyping derivation uses S-RcdWidth and S-RcdDepth to- gether to show that the nested record type {x:{a:Nat,b:Nat},y:{m:Nat}} is a subtype of {x:{a:Nat},y:{}}: S-RcdWidth {a:Nat,b:Nat} <: {a:Nat} S-RcdWidth {m:Nat} <: {} S-RcdDepth {x:{a:Nat,b:Nat},y:{m:Nat}} <: {x:{a:Nat},y:{}} If we want to use S-RcdDepth to refine the type of just a single record field (instead of refining every field, as we did in the example above), we can use S-Refl to obtain trivial subtyping derivations for the other fields. S-RcdWidth {a:Nat,b:Nat} <: {a:Nat} S-Refl {m:Nat} <: {m:Nat} S-RcdDepth {x:{a:Nat,b:Nat},y:{m:Nat}} <: {x:{a:Nat},y:{m:Nat}} 184 15 Subtyping We can also use the transitivity rule, S-Trans, to combine width and depth subtyping. For example, we can obtain a supertype by promoting the type of one field while dropping another: S-RcdWidth {x:{a:Nat,b:Nat},y:{m:Nat}} <: {x:{a:Nat,b:Nat}} S-RcdWidth {a:Nat,b:Nat} <: {a:Nat} S-RcdDepth {x:{a:Nat,b:Nat}} <: {x:{a:Nat}} S-Trans {x:{a:Nat,b:Nat},y:{m:Nat}} <: {x:{a:Nat}} Our final record subtyping rule arises from the observation that the order of fields in a record does not make any difference to how we can safely use it, since the only thing that we can do with records once we’ve built them—i.e., projecting their fields—is insensitive to the order of fields. {kj:Sj j∈1..n} is a permutation of {li:Ti i∈1..n} {kj:Sj j∈1..n} <: {li:Ti i∈1..n} (S-RcdPerm) For example, S-RcdPerm tells us that {c:Top,b:Bool,a:Nat} is a subtype of {a:Nat,b:Bool,c:Top}, and vice versa. (This implies that the subtype relation will not be anti-symmetric.) S-RcdPerm can be used in combination with S-RcdWidth and S-Trans to drop fields from anywhere in a record type, not just at the end. 15.2.1 Exercise [«]: Draw a derivation showing that {x:Nat,y:Nat,z:Nat} is a subtype of {y:Nat}. � S-RcdWidth, S-RcdDepth, and S-RcdPerm each embody a different sort of flexibility in the use of records. For purposes of discussion, it is useful to present them as three separate rules. In particular, there are languages that allow some of them but not others; for example, most variants of Abadi and Cardelli’s object calculus (1996) omit width subtyping. However, for purposes of implementation it is more convenient to combine them into a single macro- rule that does all three things at once. This rule is discussed in the next chapter (cf. page 211). Since we are working in a higher-order language, where not only numbers and records but also functions can be passed as arguments to other func- tions, we must also give a subtyping rule for function types—i.e., we must specify under what circumstances it is safe to use a function of one type in a context where a different function type is expected. T1 <: S1 S2 <: T2 S1→S2 <: T1→T2 (S-Arrow) 15.2 The Subtype Relation 185 Notice that the sense of the subtype relation is reversed (contravariant) for the argument types in the left-hand premise, while it runs in the same di- rection (covariant) for the result types as for the function types themselves. The intuition is that, if we have a function f of type S1→S2, then we know that f accepts elements of type S1; clearly, f will also accept elements of any subtype T1 of S1. The type of f also tells us that it returns elements of type S2; we can also view these results belonging to any supertype T2 of S2. That is, any function f of type S1→S2 can also be viewed as having type T1→T2. An alternative view is that it is safe to allow a function of one type S1→S2 to be used in a context where another type T1→T2 is expected as long as none of the arguments that may be passed to the function in this context will surprise it (T1 <: S1) and none of the results that it returns will surprise the context (S2 <: T2). Finally, it is convenient to have a type that is a supertype of every type. We introduce a new type constant Top, plus a rule that makes Top a maximum element of the subtype relation. S <: Top (S-Top) §15.4 discusses the Top type further. Formally, the subtype relation is the least relation closed under the rules we have given. For easy reference, Figures 15-1, 15-2, and 15-3 recapitulate the full definition of the simply typed lambda-calculus with records and subtyp- ing, highlighting the syntactic forms and rules we have added in this chapter. Note that the presence of the reflexivity and transitivity rules means that the subtype relation is clearly a preorder ; however, because of the record per- mutation rule, it is not a partial order: there are many pairs of distinct types where each is a subtype of the other. To finish the discussion of the subtype relation, let us verify that the ex- ample at the beginning of the chapter now typechecks. Using the following abbreviations to avoid running off the edge of the page, f def = λr:{x:Nat}. r.x Rx def = {x:Nat} xy def = {x=0,y=1} Rxy def = {x:Nat,y:Nat} and assuming the usual typing rules for numeric constants, we can construct a derivation for the typing statement ` f xy : Nat as follows: . . . ` f : Rx→Nat ` 0 : Nat ` 1 : Nat T-Rcd ` xy : Rxy S-RcdWidth Rxy <: Rx T-Sub ` xy : Rx T-App ` f xy : Nat 186 15 Subtyping → <: Top Based on λ→ (9-1) Syntax t ::= terms: x variable λx:T.t abstraction t t application v ::= values: λx:T.t abstraction value T ::= types: Top maximum type T→T type of functions Γ ::= contexts: ∅ empty context Γ , x:T term variable binding Evaluation t -→ t′ t1 -→ t ′ 1 t1 t2 -→ t ′ 1 t2 (E-App1) t2 -→ t ′ 2 v1 t2 -→ v1 t ′ 2 (E-App2) (λx:T11.t12) v2 -→ [x, v2]t12 (E-AppAbs) Subtyping S <: T S <: S (S-Refl) S <: U U <: T S <: T (S-Trans) S <: Top (S-Top) T1 <: S1 S2 <: T2 S1→S2 <: T1→T2 (S-Arrow) Typing Γ ` t : T x:T ∈ Γ Γ ` x : T (T-Var) Γ , x:T1 ` t2 : T2 Γ ` λx:T1.t2 : T1→T2 (T-Abs) Γ ` t1 : T11→T12 Γ ` t2 : T11 Γ ` t1 t2 : T12 (T-App) Γ ` t : S S <: T Γ ` t : T (T-Sub) Figure 15-1: Simply typed lambda-calculus with subtyping (λ <: ) 15.2.2 Exercise [«]: Is this the only derivation of the statement ` f xy : Nat? � 15.2.3 Exercise [«]: (1) How many different supertypes does {a:Top,b:Top} have? (2) Can you find an infinite descending chain in the subtype relation—that is, an infinite sequence of types S0, S1, etc. such that each Si+1 is a subtype of Si? (3) What about an infinite ascending chain? � 15.2.4 Exercise [«]: Is there a type that is a subtype of every other type? Is there an arrow type that is a supertype of every other arrow type? � 15.2 The Subtype Relation 187 → {} Extends λ→ (9-1) New syntactic forms t ::= ... terms: {li=ti i∈1..n} record t.l projection v ::= ... values: {li=vi i∈1..n} record value T ::= ... types: {li:Ti i∈1..n} type of records New evaluation rules t -→ t′ {li=vi i∈1..n}.lj -→ vj (E-ProjRcd) t1 -→ t ′ 1 t1.l -→ t ′ 1 .l (E-Proj) tj -→ t ′ j {li=vi i∈1..j−1,lj=tj,lk=tk k∈j+1..n} -→ {li=vi i∈1..j−1,lj=t ′ j,lk=tk k∈j+1..n} (E-Rcd) New typing rules Γ ` t : T for each i Γ ` ti : Ti Γ ` {li=ti i∈1..n} : {li:Ti i∈1..n} (T-Rcd) Γ ` t1 : {li:Ti i∈1..n} Γ ` t1.lj : Tj (T-Proj) Figure 15-2: Records (same as Figure 11-7) → {} <: Extends λ <: (15-1) and simple record rules (15-2) New subtyping rules S <: T {li:Ti i∈1..n+k} <: {li:Ti i∈1..n} (S-RcdWidth) for each i Si <: Ti {li:Si i∈1..n} <: {li:Ti i∈1..n} (S-RcdDepth) {kj:Sj j∈1..n} is a permutation of {li:Ti i∈1..n} {kj:Sj j∈1..n} <: {li:Ti i∈1..n} (S-RcdPerm) Figure 15-3: Records and subtyping 15.2.5 Exercise [««]: Suppose we extend the calculus with the product type con- structor T1×T2 described in §11.6. It is natural to add a subtyping rule S1 <: T1 S2 <: T2 S1×S2 <: T1×T2 (S-ProdDepth) corresponding to S-RcdDepth for records. Would it be a good idea to add a width subtyping rule for products T1×T2 <: T1 (S-ProdWidth) as well? � 188 15 Subtyping 15.3 Properties of Subtyping and Typing Having decided on the definition of the lambda-calculus with subtyping, we now have some work to do to verify that it makes sense—in particular, that the preservation and progress theorems of the simply typed lambda-calculus continue to hold in the presence of subtyping. 15.3.1 Exercise [Recommended, ««]: Before reading on, try to predict where diffi- culties might arise. In particular, suppose we had made a mistake in defining the subtype relation and included a bogus subtyping rule in addition to those above. Which properties of the system can fail? On the other hand, suppose we omit one of the subtyping rules—can any properties then break? � We begin by recording one key property of the subtype relation—an analog of the inversion lemma for the typing relation in the simply typed lambda- calculus (Lemma 9.3.1). If we know that some type S is a subtype of an arrow type, then the subtyping inversion lemma tells us that S itself must be an ar- row type; moreover, it tells us that the left-hand sides of the arrows must be (contravariantly) related, and so (covariantly) must the right-hand sides. Simi- lar considerations apply when S is known to be a subtype of a record type: we know that S has more fields (S-RcdWidth) in some order (S-RcdPerm), and that the types of common fields are in the subtype relation (S-RcdDepth). 15.3.2 Lemma [Inversion of the subtype relation]: 1. If S <: T1→T2, then S has the form S1→S2, with T1 <: S1 and S2 <: T2. 2. If S <: {li:Ti i∈1..n}, then S has the form {kj:Sj j∈1..m}, with at least the labels {li i∈1..n}—i.e., {li i∈1..n} ⊆ {kj j∈1..m}—and with Sj <: Ti for each com- mon label li = kj . � Proof: Exercise [Recommended, ««]. � To prove that types are preserved during evaluation, we begin with an in- version lemma for the typing relation (cf. Lemma 9.3.1 for the simply typed lambda-calculus). Rather than stating the lemma in its most general form, we give here just the cases that are actually needed in the proof of the preserva- tion theorem below. (The general form can be read off from the algorithmic subtype relation in the next chapter, Definition 16.2.2.) 15.3.3 Lemma: 1. If Γ ` λx:S1. s2 : T1→T2, then T1 <: S1 and Γ , x:S1 ` s2 : T2. 15.3 Properties of Subtyping and Typing 189 2. If Γ ` {ka=sa a∈1..m} : {li:Ti i∈1..n}, then {li i∈1..n} ⊆ {ka a∈1..m} and Γ ` sa : Ti for each common label ka = li . � Proof: Straightforward induction on typing derivations, using Lemma 15.3.2 for the T-Sub case. � Next, we need a substitution lemma for the typing relation. The statement of this lemma is unchanged from the simply typed lambda-calculus (Lemma 9.3.8), and its proof is nearly identical. 15.3.4 Lemma [Substitution]: If Γ , x:S ` t : T and Γ ` s : S, then Γ ` [x , s]t : T. � Proof: By induction on typing derivations. We need new cases for T-Sub and for the record typing rules T-Rcd and T-Proj, making straightforward use of the induction hypothesis. The rest is just like the proof of 9.3.8. � Now, the preservation theorem has the same statement as before. Its proof, though, is somewhat complicated by subtyping at several points. 15.3.5 Theorem [Preservation]: If Γ ` t : T and t -→ t′, then Γ ` t′ : T. � Proof: Straightforward induction on typing derivations. Most of the cases are similar to the proof of preservation for the simply typed lambda-calculus (9.3.9). We need new cases for the record typing rules and for subsumption. Case T-Var: t = x Can’t happen (there are no evaluation rules for variables). Case T-Abs: t = λx:T1.t2 Can’t happen (t is already a value). Case T-App: t = t1 t2 Γ ` t1 : T11→T12 Γ ` t2 : T11 T = T12 From the evaluation rules in Figures 15-1 and 15-2, we see that there are three rules by which t -→ t′ can be derived: E-App1, E-App2, and E-AppAbs. Proceed by cases. Subcase E-App1: t1 -→ t ′ 1 t′ = t′ 1 t2 The result follows from the induction hypothesis and T-App. Subcase E-App2: t1 = v1 t2 -→ t ′ 2 t′ = v1 t ′ 2 Similar. Subcase E-AppAbs: t1 = λx:S11. t12 t2 = v2 t ′ = [x, v2]t12 By Lemma 15.3.3(1), T11 <: S11 and Γ , x:S11 ` t12 : T12. By T-Sub, Γ ` t2 : S11. From this and the substitution lemma (15.3.4), we obtain Γ ` t ′ : T12. 190 15 Subtyping Case T-Rcd: t = {li=ti i∈1..n} Γ ` ti : Ti for each i T = {li:Ti i∈1..n} The only evaluation rule whose left-hand side is a record is E-Rcd. From the premise of this rule, we see that tj -→ t ′ j for some field tj . The result follows from the induction hypothesis (applied to the corresponding assumption Γ ` tj : Tj ) and T-Rcd. Case T-Proj: t = t1.lj Γ ` t1 : {li:Ti i∈1..n} T = Tj From the evaluation rules in Figures 15-1 and 15-2, we see that there are two rules by which t -→ t′ can be derived: E-Proj, E-ProjRcd. Subcase E-Proj: t1 -→ t ′ 1 t′ = t′ 1 .lj The result follows from the induction hypothesis and T-Proj. Subcase E-ProjRcd: t1 = {ka=va a∈1..m} lj = kb t ′ = vb By Lemma 15.3.3(2), we have {li i∈1..n} ⊆ {ka a∈1..m} and Γ ` va : Ti for each ka = li . In particular, Γ ` vb : Tj , as desired. Case T-Sub: t : S S <: T By the induction hypothesis, Γ ` t′ : S. By T-Sub, Γ ` t : T. � To prove that well-typed terms cannot get stuck, we begin (as in Chapter 9) with a canonical forms lemma, which tells us the possible shapes of values belonging to arrow and record types. 15.3.6 Lemma [Canonical Forms]: 1. If v is a closed value of type T1→T2, then v has the form λx:S1.t2. 2. If v is a closed value of type {li:Ti i∈1..n}, then v has the form {kj=vj a∈1..m}, with {li i∈1..n} ⊆ {ka a∈1..m}. � Proof: Exercise [Recommended, «««]. � The progress theorem and its proof are now quite close to what we saw in the simply typed lambda-calculus. Most of the burden of dealing with subtyp- ing has been pushed into the canonical forms lemma, and only a few small changes are needed here. 15.3.7 Theorem [Progress]: If t is a closed, well-typed term, then either t is a value or else there is some t′ with t -→ t′. � Proof: By straightforward induction on typing derivations. The variable case cannot occur (because t is closed). The case for lambda-abstractions is imme- diate, since abstractions are values. The remaining cases are more interesting. 15.4 The Top and Bottom Types 191 Case T-App: t = t1 t2 ` t1 : T11→T12 ` t2 : T11 T = T12 By the induction hypothesis, either t1 is a value or else it can make a step of evaluation; likewise t2. If t1 can take a step, then rule E-App1 applies to t. If t1 is a value and t2 can take a step, then rule E-App2 applies. Finally, if both t1 and t2 are values, then the canonical forms lemma (15.3.6) tells us that t1 has the form λx:S11.t12, so rule E-AppAbs applies to t. Case T-Rcd: t = {li=ti i∈1..n} for each i ∈ 1..n, ` ti : Ti T = {li:Ti i∈1..n} By the induction hypothesis, each ti either is already a value or can make a step of evaluation. If all of them are values, then t is a value. On the other hand, if at least one can make a step, then rule E-Rcd applies to t. Case T-Proj: t = t1.lj ` t1 : {li:Ti i∈1..n} T = Tj By the induction hypothesis, either t1 is a value or it can make an evaluation step. If t1 can make a step, then (by E-Proj) so can t. If t1 is a value, then by the canonical forms lemma (15.3.6) t1 has the form {ka=vj a∈1..m}, with {li i∈1..n} ⊆ {ka a∈1..m} and with ` vj : Ti for each li = kj . In particular, lj is among the labels {ka a∈1..m} of t1, from which rule E-ProjRcd tells us that t itself can take an evaluation step. Case T-Sub: Γ ` t : S S <: T The result follows directly from the induction hypothesis. � 15.4 The Top and Bottom Types The maximal type Top is not a necessary part of the simply typed lambda- calculus with subtyping; it can be removed without damaging the properties of the system. However, it is included in most presentations, for several rea- sons. First, it corresponds to the type Object found in most object-oriented languages. Second, Top is a convenient technical device in more sophisticated systems combining subtyping and parametric polymorphism. For example, in System F<: (Chapters 26 and 28), the presence of Top allows us to recover or- dinary unbounded quantification from bounded quantification, streamlining the system. Indeed, even records can be encoded in F<:, further streamlining the presentation (at least for purposes of formal study); this encoding criti- cally depends on Top. Finally, since Top’s behavior is straightforward and it is often useful in examples, there is little reason not to keep it. It is natural to ask whether we can also complete the subtype relation with a minimal element—a type Bot that is a subtype of every type. The answer is that we can: this extension is formalized in Figure 15-4. The first thing to notice is that Bot is empty—there are no closed values 192 15 Subtyping → <: Bot Extends λ <: (15-1) New syntactic forms T ::= ... types: Bot minimum type New subtyping rules S <: T Bot <: T (S-Bot) Figure 15-4: Bottom type of type Bot. If there were one, say v, then the subsumption rule plus S-Bot would allow us to derive ` v : Top→Top, from which the canonical forms lemma (15.3.6, which still holds under the extension) tells us that v must have the form λx:S1.t2 for some S1 and t2. On the other hand, by subsumption, we also have ` v : {}, from which the canonical forms lemma tells us that v must be a record. The syntax makes it clear that v cannot be both a function and a record, and so assuming that ` v : Bot has led us to a contradiction. The emptiness of Bot does not make it useless. On the contrary: Bot pro- vides a very convenient way of expressing the fact that some operations (in particular, throwing an exception or invoking a continuation) are not intended to return. Giving such expressions the type Bot has two good effects: first, it signals to the programmer that no result is expected (since if the expression did return a result, it would be a value of type Bot); second, it signals to the typechecker that such an expression can safely be used in a context expect- ing any type of value. For example, if the exception-raising term error from Chapter 14 is given type Bot, then a term like λx:T. if then

else

error

will be well typed because, no matter what the type of the normal result is,

the term error can always be given the same type by subsumption, so the

two branches of the if are compatible, as required by T-If.1

Unfortunately, the presence of Bot significantly complicates the problem

of building a typechecker for the system. A simple typechecking algorithm for

1. In languages with polymorphism, such as ML, we can also use ∀X.X as a result type for

error and similar constructs. This achieves the same effect as Bot by different means: instead

of giving error a type that can be promoted to any type, we give it a type scheme that can be

instantiated to any type. Though they rest on different foundations, the two solutions are quite

similar: in particular, the type ∀X.X is also empty.

15.5 Subtyping and Other Features 193

a language with subtyping needs to rely on inferences like “if an application

t1 t2 is well typed, then t1 must have an arrow type.” In the presence of Bot,

we must refine this to “if t1 t2 is well typed, then t1 must have either an

arrow type or type Bot”; this point is expanded in §16.4. The complications

are magnified further in systems with bounded quantification; see §28.8.

These complications show that adding Bot is a more serious step than

adding Top. We shall omit it from the systems we consider in the remainder

of the book.

15.5 Subtyping and Other Features

As we extend our simple calculus with subtyping toward a full-blown pro-

gramming language, each new feature must be examined carefully to see how

it interacts with subtyping. In this section we consider some of the features

we have seen at this point.2 Later chapters will take up the (significantly

more complex) interactions between subtyping and features such as paramet-

ric polymorphism (Chapters 26 and 28), recursive types (Chapters 20 and 21),

and type operators (Chapter 31).

Ascription and Casting

The ascription operator t as T was introduced in §11.4 as a form of checked

documentation, allowing the programmer to record in the text of the program

the assertion that some subterm of a complex expression has some particular

type. In the examples in this book, ascription is also used to control the way

in which types are printed, forcing the typechecker to use a more readable

abbreviated form instead of the type that it has actually calculated for a term.

In languages with subtyping such as Java and C++, ascription becomes

quite a bit more interesting. It is often called casting in these languages, and

is written (T)t. There are actually two quite different forms of casting—so-

called up-casts and down-casts. The former are straightforward; the latter,

which involve dynamic type-testing, require a significant extension.

Up-casts, in which a term is ascribed a supertype of the type that the type-

checker would naturally assign it, are instances of the standard ascription

operator. We give a term t and a type T at which we intend to “view” t. The

typechecker verifies that T is indeed one of the types of t by attempting to

build a derivation

2. Most of the extensions discussed in this section are not implemented in the fullsub

checker.

194 15 Subtyping

…

Γ ` t : S

…

S <: T T-Sub Γ ` t : T T-Ascribe Γ ` t as T : T using the “natural” typing of t, the subsumption rule T-Sub, and the ascrip- tion rule from §11.4: Γ ` t1 : T Γ ` t1 as T : T (T-Ascribe) Up-casts can be viewed as a form of abstraction—a way of hiding the existence of some parts of a value so that they cannot be used in some surrounding context. For example, if t is a record (or, more generally, an object), then we can use an up-cast to hide some of its fields (methods). A down-cast, on the other hand, allows us to assign types to terms that the typechecker cannot derive statically. To allow down-casts, we make a some- what surprising change to the typing rule for as: Γ ` t1 : S Γ ` t1 as T : T (T-Downcast) That is, we check that t1 is well typed (i.e., that it has some type S) and then assign it type T, without making any demand about the relation between S and T. For example, using down-casting we can write a function f that takes any argument whatsoever, casts it down to a record with an a field containing a number, and returns this number: f = λ(x:Top) (x as {a:Nat}).a; In effect, the programmer is saying to the typechecker, “I know (for reasons that are too complex to explain in terms of the typing rules) that f will always be applied to record arguments with numeric a fields; I want you to trust me on this one.” Of course, blindly trusting such assertions will have a disastrous effect on the safety of our language: if the programmer somehow makes a mistake and applies f to a record that does not contain an a field, the results might (depending on the details of the compiler) be completely arbitrary! Instead, our motto should be “trust, but verify.” At compile time, the typechecker simply accepts the type given in the down-cast. However, it inserts a check that, at run time, will verify that the actual value does indeed have the type claimed. In other words, the evaluation rule for ascriptions should not just discard the annotation, as our original evaluation rule for ascriptions did, v1 as T -→ v1 (E-Ascribe) 15.5 Subtyping and Other Features 195 but should first compare the actual (run-time) type of the value with the de- clared type: ` v1 : T v1 as T -→ v1 (E-Downcast) For example, if we apply the function f above to the argument {a=5,b=true}, then this rule will check (successfully) that ` {a=5,b=true} : {a:Nat}. On the other hand, if we apply f to {b=true}, then the E-Downcast rule will not apply and evaluation will get stuck at this point. This run-time check recovers the type preservation property. 15.5.1 Exercise [«« 3]: Prove this. � Of course, we lose progress, since a well-typed program can certainly get stuck by attempting to evaluate a bad down-cast. Languages that provide down-casts normally address this in one of two ways: either by making a failed down-cast raise a dynamic exception that can be caught and handled by the program (cf. Chapter 14) or else by replacing the down-cast operator by a form of dynamic type test: Γ ` t1 : S Γ , x:T ` t2 : U Γ ` t3 : U Γ ` if t1 in T then x→t2 else t3 : U (T-Typetest) ` v1 : T if v1 in T then x→t2 else t3 -→ [x, v1]t2 (E-Typetest1) 6` v1 : T if v1 in T then x→t2 else t3 -→ t3 (E-Typetest2) Uses of down-casts are actually quite common in languages like Java. In particular, down-casts support a kind of “poor-man’s polymorphism.” For example, “collection classes” such as Set and List are monomorphic in Java: instead of providing a type List T (lists containing elements of type T) for every type T, Java provides just List, the type of lists whose elements belong to the maximal type Object. Since Object is a supertype of every other type of objects in Java, this means that lists may actually contain anything at all: when we want to add an element to a list, we simply use subsumption to promote its type to Object. However, when we take an element out of a list, all the typechecker knows about it is that it has type Object. This type does not warrant calling most of the methods of the object, since the type Object mentions only a few very generic methods for printing and such, which are shared by all Java objects. In order to do anything useful with it, we must first downcast it to some expected type T. It has been argued—for example, by the designers of Pizza (Odersky and Wadler, 1997), GJ (Bracha, Odersky, Stoutamire, and Wadler, 1998), PolyJ (My- 196 15 Subtyping ers, Bank, and Liskov, 1997), and NextGen (Cartwright and Steele, 1998)—that it is better to extend the Java type system with real polymorphism (cf. Chap- ter 23), which is both safer and more efficient than the down-cast idiom, requiring no run-time tests. On the other hand, such extensions add signif- icant complexity to an already-large language, interacting with many other features of the language and type system (see Igarashi, Pierce, and Wadler, 1999, Igarashi, Pierce, and Wadler, 2001, for example); this fact supports a view that the down-cast idiom offers a reasonable pragmatic compromise between safety and complexity. Down-casts also play a critical role in Java’s facilities for reflection. Using reflection, the programmer can tell the Java run-time system to dynamically load a bytecode file and create an instance of some class that it contains. Clearly, there is no way that the typechecker can statically predict the shape of the class that will be loaded at this point (the bytecode file can be obtained on demand from across the net, for example), so the best it can do is to assign the maximal type Object to the newly created instance. Again, in order to do anything useful, we must downcast the new object to some expected type T, handle the run-time exception that may result if the class provided by the bytecode file does not actually match this type, and then go ahead and use it with type T. To close the discussion of down-casts, a note about implementation is in order. It seems, from the rules we have given, that including down-casts to a language involves adding all the machinery for typechecking to the run- time system. Worse, since values are typically represented differently at run time than inside the compiler (in particular, functions are compiled into byte- codes or native machine instructions), it appears that we will need to write a different typechecker for calculating the types needed in dynamic checks. To avoid this, real languages combine down-casts with type tags—single-word tags (similar in some ways to ML’s datatype constructors and the variant tags in §11.10) that capture a run-time “residue” of compile-time types and that are sufficient to perform dynamic subtype tests. Chapter 19 develops one instance of this mechanism in detail. Variants The subtyping rules for variants (cf. §11.10) are nearly identical to the ones for records; the only difference is that the width rule S-VariantWidth al- lows new variants to be added, not dropped, when moving from a subtype to a supertype. The intuition is that a tagged expression belongs to a

variant type if its label l is one of the possible labels {li} listed in

the type; adding more labels to this set decreases the information it gives us

15.5 Subtyping and Other Features 197

→ <> <: Extends λ <: (15-1) and simple variant rules (11-11) New syntactic forms t ::= ... terms: (no as) tagging

New typing rules Γ ` t : T

Γ ` t
1
: T

1

Γ ` :

(T-Variant)

New subtyping rules S <: T <:

(S-VariantWidth)

for each i Si <: Ti <:

(S-VariantDepth)

is a permutation of

<:

(S-VariantPerm)

Figure 15-5: Variants and subtyping

about its elements. A singleton variant type tells us precisely what

label its elements are tagged with; a two-variant type tells

us that its elements have either label l1 or label l2, etc. Conversely, when we

use variant values, it is always in the context of a case statement, which must

have one branch for each variant listed by the type—listing more variants just

means forcing case statements to include some unnecessary extra branches.

Another consequence of combining subtyping and variants is that we can

drop the annotation from the tagging construct, writing just instead

of as , as we did in §11.10, and changing the typing rule

for tagging so that it assigns the precise type . We can then

use subsumption plus S-VariantWidth to obtain any larger variant type.

Lists

We have seen a number of examples of covariant type constructors (records

and variants, as well as function types, on their right-hand sides) and one

contravariant constructor (arrow, on the left-hand side). The List constructor

is also covariant: if we have a list whose elements have type S1, and S1 <: T1, then we can safely regard our list as having elements of type T1. S1 <: T1 List S1 <: List T1 (S-List) 198 15 Subtyping References Not all type constructors are covariant or contravariant. The Ref constructor, for example, must be taken to be invariant in order to preserve type safety. S1 <: T1 T1 <: S1 Ref S1 <: Ref T1 (S-Ref) For Ref S1 to be a subtype of Ref T1, we demand that S1 and T1 be equiva- lent under the subtype relation—each a subtype of the other. This gives us the flexibility to reorder the fields of records under a Ref constructor—for example, Ref {a:Bool,b:Nat} <: Ref {b:Nat,a:Bool}—but nothing more. The reason for this very restrictive subtyping rule is that a value of type Ref T1 can be used in a given context in two different ways: for both reading (!) and writing (:=). When it is used for reading, the context expects to obtain a value of type T1, so if the reference actually yields a value of type S1 then we need S1 <: T1 to avoid violating the context’s expectations. On the other hand, if the same reference cell is used for writing, then the new value provided by the context will have type T1. If the actual type of the reference is Ref S1, then someone else may later read this value and use it as an S1; this will be safe only if T1 <: S1. 15.5.2 Exercise [« 3]: (1) Write a short program that will fail with a run-time type error (i.e., its evaluation will get stuck) if the first premise of S-Ref is dropped. (2) Write another program that will fail if the second premise is dropped. � Arrays Clearly, the motivations behind the invariant subtyping rule for references also apply to arrays, since the operations on arrays include forms of both dereferencing and assignment. S1 <: T1 T1 <: S1 Array S1 <: Array T1 (S-Array) Interestingly, Java actually permits covariant subtyping of arrays: S1 <: T1 Array S1 <: Array T1 (S-ArrayJava) (in Java syntax, S1[] <: T1[]). This feature was originally introduced to com- pensate for the lack of parametric polymorphism in the typing of some basic operations such as copying parts of arrays, but is now generally considered a flaw in the language design, since it seriously affects the performance of pro- grams involving arrays. The reason is that the unsound subtyping rule must be compensated with a run-time check on every assignment to any array, to 15.5 Subtyping and Other Features 199 make sure the value being written belongs to (a subtype of) the actual type of the elements of the array. 15.5.3 Exercise [««« 3]: Write a short Java program involving arrays that type- checks but fails (by raising an ArrayStoreException) at run time. � References Again A more refined analysis of references, first explored by Reynolds in the lan- guage Forsythe (1988), can be obtained by introducing two new type construc- tors, Source and Sink. Intuitively, Source T is thought of as a capability to read values of type T from a cell (but which does not permit assignment), while Sink T is a capability to write to a cell. Ref T is a combination of these two capabilities, giving permission both to read and to write. The typing rules for dereferencing and assignment (Figure 13-1) are modi- fied so that they demand only the appropriate capability. Γ | Σ ` t1 : Source T11 Γ | Σ ` !t1 : T11 (T-Deref) Γ | Σ ` t1 : Sink T11 Γ | Σ ` t2 : T11 Γ | Σ ` t1:=t2 : Unit (T-Assign) Now, if we have only the capability to read values from a cell and if these values are guaranteed to have type S1, then it is safe to “downgrade” this to a capability to read values of type T1, as long as S1 is a subtype of T1. That is, the Source constructor is covariant. S1 <: T1 Source S1 <: Source T1 (S-Source) Conversely, a capability to write values of type S1 to a given cell can be down- graded to a capability to write values of some smaller type T1: the Sink con- structor is contravariant. T1 <: S1 Sink S1 <: Sink T1 (S-Sink) Finally, we express the intuition that Ref T1 is a combination of read and write capabilities by two subtyping rules that permit a Ref to be downgraded to either a Source or a Sink. Ref T1 <: Source T1 (S-RefSource) Ref T1 <: Sink T1 (S-RefSink) 200 15 Subtyping Channels The same intuitions (and identical subtyping rules) form the basis for the treatment of channel types in recent concurrent programming languages such as Pict (Pierce and Turner, 2000; Pierce and Sangiorgi, 1993). The key obser- vation is that, from the point of view of typing, a communication channel behaves exactly like a reference cell: it can be used for both reading and writ- ing, and, since it is difficult to determine statically which reads correspond to which writes, the only simple way to ensure type safety is to require that all the values passed along the channel must belong to the same type. Now, if we pass someone only the capability to write to a given channel, then it is safe for them to pass this capability to someone else who promises to write values of a smaller type—the “output channel” type constructor is contravari- ant. Similarly, if we pass just the capability to read from a channel, then this capability can safely be downgraded to a capability for reading values of any larger type—the “input channel” constructor is covariant. Base Types In a full-blown language with a rich set of base types, it is often convenient to introduce primitive subtype relations among these types. For example, in many languages the boolean values true and false are actually represented by the numbers 1 and 0. We can, if we like, expose this fact to the programmer by introducing a subtyping axiom Bool <: Nat. Now we can write compact expressions like 5*b instead of if b then 5 else 0. 15.6 Coercion Semantics for Subtyping Throughout this chapter, our intuition has been that subtyping is “semanti- cally insignificant.” The presence of subtyping does not change the way pro- grams are evaluated; rather, subtyping is just a way of obtaining additional flexibility in typing terms. This interpretation is simple and natural, but it car- ries some performance penalties—particularly for numerical calculations and for accessing record fields—that may not be acceptable in high-performance implementations. We sketch here an alternative coercion semantics and dis- cuss some new issues that it, in its turn, raises. This section can be skipped if desired. 15.6 Coercion Semantics for Subtyping 201 Problems with the Subset Semantics As we saw in §15.5, it can be convenient to allow subtyping between dif- ferent base types. But some “intuitively reasonable” inclusions between base types may have a detrimental effect on performance. For example, suppose we introduce the axiom Int <: Float, so that integers can be used in floating- point calculations without writing explicit coercions—allowing us to write, for example, 4.5 + 6 instead of 4.5 + intToFloat(6). Under the subset seman- tics, this implies that the set of integer values must literally be a subset of the set of floats. But, on most real machines, the concrete representations of integers and floats are entirely different: integers are usually represented in twos-complement form, while floats are divided up into mantissa, exponent, and sign, plus some special cases such as NaN (not-a-number). To reconcile these representational differences with the subset semantics of subtyping, we can adopt a common tagged (or boxed) representation for numbers: an integer is represented as a machine integer plus a tag (either in a separate header word or in the high-order bits of the same word as the actual integer), and a float is represented as a machine float plus a different tag. The type Float then refers to the entire set of tagged numbers (floats and ints), while Int refers just to the tagged ints. This scheme is not unreasonable: it corresponds to the representation strat- egy actually used in many modern language implementations, where the tag bits (or words) are also needed to support garbage collection. The downside is that every primitive operation on numbers must actually be implemented as a tag check on the arguments, a few instructions to unbox the primitive num- bers, one instruction for the actual operation, and a couple of instructions for re-boxing the result. Clever compiler optimizations can eliminate some of this overhead, but, even with the best currently available techniques, it sig- nificantly degrades performance, especially in heavily numeric code such as graphical and scientific calculations. A different performance problem arises when records are combined with subtyping—in particular, with the permutation rule. Our simple evaluation rule for field projection {li=vi i∈1..n}.lj -→ vj (E-ProjRcd) can be read as “search for lj among the labels of the record, and yield the associated value vj .” But, in a real implementation, we certainly do not want to perform a linear search at run time through the fields of the record to find the desired label. In a language without subtyping (or with subtyping but without the permutation rule), we can do much better: if the label lj appears third in the type of the record, then we know statically that all run- time values with this type will have lj as their third field, so at run time we 202 15 Subtyping do not need to look at the labels at all (in fact, we can omit them completely from the run-time representation, effectively compiling records into tuples). To obtain the value of the lj field, we generate an indirect load through a register pointing to the start of the record, with a constant offset of 3 words. The presence of the permutation rule foils this technique, since knowing that some record value belongs to a type where lj appears as the third field tells us nothing at all, now, about where the lj field is actually stored in the record. Again, clever optimizations and run-time tricks can palliate this problem, but in general field projection can require some form of search at run time.3 Coercion Semantics We can address both of these problems by adopting a different semantics, in which we “compile away” subtyping by replacing it with run-time coercions. If an Int is promoted to a Float during typechecking, for example, then at run time we physically change this number’s representation from a machine integer to a machine float. Similarly, a use of the record permutation sub- typing rule will be compiled into a piece of code that literally rearranges the order of the fields. Primitive numeric operations and field accesses can now proceed without the overhead of unboxing or search. Intuitively, the coercion semantics for a language with subtyping is ex- pressed as a function that transforms terms from this language into a lower- level language without subtyping. Ultimately, the low-level language might be machine code for some concrete processor. For purposes of illustration, however, we can keep the discussion on a more abstract level. For the source language, we choose the one we have been using for most of the chapter— the simply typed lambda-calculus with subtyping and records. For the low- level target language, we choose the pure simply typed lambda-calculus with records and a Unit type (which we use to interpret Top). Formally, the compilation consists of three translation functions—one for types, one for subtyping, and one for typing. For types, the translation just replaces Top with Unit. We write this function as [[—]]. [[Top]] = Unit [[T1→T2]] = [[T1]]→[[T2]] [[{li:Ti i∈1..n}]] = {li:[[Ti]] i∈1..n} 3. Similar observations apply to accessing fields and methods of objects, in languages where object subtyping allows permutation. This is the reason that Java, for example, restricts sub- typing between classes so that new fields can only be added at the end. Subtyping between interfaces (and between classes and interfaces) does allow permutation—if it did not, inter- faces would be of hardly any use—and the manual explicitly warns that looking up a method from an interface will in general be slower than from a class. 15.6 Coercion Semantics for Subtyping 203 For example, [[Top→{a:Top,b:Top}]] = Unit→{a:Unit,b:Unit}. (The other translations will also be written [[—]]; the context will always make it clear which one we are talking about.) To translate a term, we need to know where subsumption is used in type- checking it, since these are the places where run-time coercions will be in- serted. One convenient way of formalizing this observation is to give the translation as a function on derivations of typing statements. Similarly, to generate a coercion function transforming values of type S to type T, we need to know not just that S is a subtype of T, but also why. We accomplish this by generating coercions from subtyping derivations. A little notation for naming derivations is needed to formalize the trans- lations. Write C :: S <: T to mean “C is a subtyping derivation tree whose conclusion is S <: T.” Similarly, write D :: Γ ` t : T to mean “D is a typing derivation whose conclusion is Γ ` t : T.” Let us look first at the function that, given a derivation C for the subtyping statement S <: T, generates a coercion [[C]]. This coercion is nothing but a function (in the target language of the translation, λ→) from type [[S]] to type [[T]]. The definition goes by cases on the final rule used in C. [[ T <: T (S-Refl) ]] = λx:[[T]]. x [[ S <: Top (S-Top) ]] = λx:[[S]]. unit [[ C1 :: S <: U C2 :: U <: T S <: T (S-Trans) ]] = λx:[[S]]. [[C2]]([[C1]] x) [[ C1 :: T1 <: S1 C2 :: S2 <: T2 S1→S2 <: T1→T2 (S-Arrow) ]] = λf:[[S1→S2]]. λx:[[T1]]. [[C2]](f([[C1]] x)) [[ {li:Ti i∈1..n+k} <: {li:Ti i∈1..n} (S-RcdWidth) ]] = λr:{li:[[Ti]] i∈1..n+k}. {li=r.li i∈1..n} [[ for each i Ci :: Si <: Ti {li:Si i∈1..n} <: {li:Ti i∈1..n} (S-RcdDepth) ]] = λr:{li:[[Si]] i∈1..n}. {li=[[Ci]](r.li) i∈1..n} [[ {kj:Sj j∈1..n} perm. of {li:Ti i∈1..n} {li:Si i∈1..n} <: {li:Ti i∈1..n} (S-RcdPerm) ]] = λr:{kj:[[Si]] j∈1..n}. {li=r.li i∈1..n} 15.6.1 Lemma: If C :: S <: T, then ` [[C]] : [[S]]→[[T]]. � Proof: Straightforward induction on C. � Typing derivations are translated in a similar way. IfD is a derivation of the statement Γ ` t : T, then its translation [[D]] is a target-language term of type 204 15 Subtyping [[T]]. This translation function is often called the Penn translation, after the group at the University of Pennsylvania that first studied it (Breazu-Tannen, Coquand, Gunter, and Scedrov, 1991). [[ x:T ∈ Γ Γ ` x : T (T-Var) ]] = x [[ D2 :: Γ , x:T1 ` t2 : T2 Γ ` λx:T1 : T1→T2 (T-Abs) ]] = λx:[[T1]]. [[D2]] [[ D1 :: Γ ` t1 : T11→T12 D2 :: Γ ` t2 : T11 Γ ` t1 t2 : T12 (T-App) ]] = [[D1]] [[D2]] [[ for each i Di :: Γ ` ti : Ti Γ ` {li=ti i∈1..n} : {li:Ti i∈1..n} (T-Rcd) ]] = {li=[[Di]] i∈1..n} [[ D1 :: Γ ` t1 : {li:Ti i∈1..n} Γ ` t1.lj : Tj (T-Proj) ]] = [[D1]].lj [[ D :: Γ ` t : S C :: S <: T Γ ` t : T (T-Sub) ]] = [[C]] [[D]] 15.6.2 Theorem: If D :: Γ ` t : T, then [[Γ]] ` [[D]] : [[T]], where [[Γ]] is the point- wise extension of the type translation to contexts: [[∅]] = ∅ and [[Γ , x:T]] = [[Γ]], x:[[T]]. � Proof: Straightforward induction on D, using Lemma 15.6.1 for the T-Sub case. � Having defined these translations, we can drop the evaluation rules for the high-level language with subtyping, and instead evaluate terms by typecheck- ing them (using the high-level typing and subtyping rules), translating their typing derivations to the low-level target language, and then using the evalua- tion relation of this language to obtain their operational behavior. This strat- egy is actually used in some high-performance implementations of languages with subtyping, such as the Yale compiler group’s experimental Java compiler (League, Shao, and Trifonov, 1999; League, Trifonov, and Shao, 2001). 15.6.3 Exercise [««« 3]: Modify the translations above to use simply typed lambda- calculus with tuples (instead of records) as a target language. Check that The- orem 15.6.2 still holds. � Coherence When we give a coercion semantics for a language with subtyping, there is a potential pitfall that we need to be careful to avoid. Suppose, for example, 15.6 Coercion Semantics for Subtyping 205 that we extend the present language with the base types Int, Bool, Float, and String. The following primitive coercions might all be useful: [[Bool <: Int]] = λb:Bool. if b then 1 else 0 [[Int <: String]] = intToString [[Bool <: Float]] = λb:Bool. if b then 1.0 else 0.0 [[Float <: String]] = floatToString The functions intToString and floatToString are primitives that con- struct string representations of numbers. For the sake of the example, sup- pose that intToString(1) = "1", while floatToString(1.0) = "1.000". Now, suppose we are asked to evaluate the term (λx:String.x) true; using the coercion semantics. This term is typable, given the axioms above for the primitive types. In fact, it is typable in two distinct ways: we can either use subsumption to promote Bool to Int and then to String, to show that true is an appropriate argument to a function of type String→String, or we can promote Bool to Float and then to String. But if we translate these derivations into λ→, we get different behaviors. If we coerce true to type Int, we get 1, from which intToString yields the string "1". But if we instead coerce true to a float and then, using floatToString, to a String (following the structure of a typing derivation in which true : String is proved by going via Float), we obtain "1.000". But "1" and "1.000" are very different strings: they do not even have the same length. In other words, the choice of how to prove ` (λx:String. x) true : String affects the way the translated program behaves! But this choice is completely internal to the compiler—the programmer writes only terms, not derivations—so we have designed a language in which programmers cannot control or even predict the behavior of the programs they write. The appropriate response to such problems is to impose an additional re- quirement, called coherence, on the definition of the translation functions. 15.6.4 Definition: A translation [[—]] from typing derivations in one language to terms in another is coherent if, for every pair of derivations D1 and D2 with the same conclusion Γ ` t : T, the translations [[D1]] and [[D2]] are behav- iorally equivalent terms of the target language. � In particular, the translations given above (with no base types) are coherent. To recover coherence when we consider base types (with the axioms above), it suffices to change the definition of the floatToString primitive so that floatToString(0.0) = "0" and floatToString(1.0) = "1". 206 15 Subtyping Proving coherence, especially for more complex languages, can be a tricky business. See Reynolds (1980), Breazu-Tannen et al. (1991), Curien and Ghelli (1992), and Reynolds (1991). 15.7 Intersection and Union Types A powerful refinement of the subtype relation can be obtained by adding an intersection operator to the language of types. Intersection types were in- vented by Coppo, Dezani, Sallé, and Pottinger (Coppo and Dezani-Ciancaglini, 1978; Coppo, Dezani-Ciancaglini, and Sallé, 1979; Pottinger, 1980). Accessible introductions can be found in Reynolds (1988, 1998b), Hindley (1992), and Pierce (1991b). The inhabitants of the intersection type T1 ∧ T2 are terms belonging to both S and T—that is, T1 ∧ T2 is an order-theoretic meet (greatest lower bound) of T1 and T2. This intuition is captured by three new subtyping rules. T1 ∧ T2 <: T1 (S-Inter1) T1 ∧ T2 <: T2 (S-Inter2) S <: T1 S <: T2 S <: T1 ∧ T2 (S-Inter3) One additional rule allows a natural interaction between intersection and ar- row types. S→T1 ∧ S→T2 <: S→(T1∧T2) (S-Inter4) The intuition behind this rule is that, if we know a term has the function types S→T1 and S→T2, then we can certainly pass it an S and expect to get back both a T1 and a T2. The power of intersection types is illustrated by the fact that, in a call- by-name variant of the simply typed lambda-calculus with subtyping and in- tersections, the set of untyped lambda-terms that can be assigned types is exactly the set of normalizing terms—i.e., a term is typable iff its evaluation terminates! This immediately implies that the type reconstruction problem (see Chapter 22) for calculi with intersections is undecidable. More pragmatically, the interest of intersection types is that they sup- port a form of finitary overloading. For example, we might assign the type (Nat→Nat→Nat) ∧ (Float→Float→Float) to an addition operator that can be used on both natural numbers and floats (using tag bits in the run- time representation of its arguments, for example, to select the correct in- struction). Unfortunately, the power of intersection types raises some difficult prag- matic issues for language designers. So far, only one full-scale language, 15.8 Notes 207 Forsythe (Reynolds, 1988), has included intersections in their most general form. A restricted form known as refinement types may prove more manage- able (Freeman and Pfenning, 1991; Pfenning, 1993b; Davies, 1997). The dual notion of union types, T1 ∨ T2, also turns out to be quite useful. Unlike sum and variant types (which, confusingly, are sometimes also called “unions”), T1 ∨ T2 denotes the ordinary union of the set of values belonging to T1 and the set of values belonging to T2, with no added tag to identify the origin of a given element. Thus, Nat ∨ Nat is actually just another name for Nat. Non-disjoint union types have long played an important role in program analysis (Palsberg and Pavlopoulou, 1998), but have featured in few program- ming languages (notably Algol 68; cf. van Wijngaarden et al., 1975); recently, though, they are increasingly being applied in the context of type systems for processing of “semistructured” database formats such as XML (Buneman and Pierce, 1998; Hosoya, Vouillon, and Pierce, 2001). The main formal difference between disjoint and non-disjoint union types is that the latter lack any kind of case construct: if we know only that a value v has type T1 ∨ T2, then the only operations we can safely perform on v are ones that make sense for both T1 and T2. (For example, if T1 and T2 are records, it makes sense to project v on their common fields.) The untagged union type in C is a source of type safety violations precisely because it ignores this restriction, allowing any operation on an element of T1 ∨ T2 that makes sense for either T1 or T2. 15.8 Notes The idea of subtyping in programming languages goes back to the 1960s, in Simula (Birtwistle, Dahl, Myhrhaug, and Nygaard, 1979) and its relatives. The first formal treatments are due to Reynolds (1980) and Cardelli (1984). The typing and—especially—subtyping rules dealing with records are some- what heavier than most of the other rules we have seen, involving either vari- able numbers of premises (one for each field) or additional mechanisms like permutations on the indices of fields. There are many other ways of writing these rules, but all either suffer from similar complexity or else avoid it by in- troducing informal conventions (e.g., ellipsis: “l1:T1 . . . ln:Tn”). Frustration with this state of affairs led Cardelli and Mitchell to develop their calculus of Operations on Records (1991), in which the macro operation of creating a multi-field record is broken down into a basic empty record value plus an operation for adding a single field at a time. Additional operations such as in-place field update and record concatenation (Harper and Pierce, 1991) can also be considered in this setting. The typing rules for these operations be- 208 15 Subtyping come rather subtle, especially in the presence of parametric polymorphism, so most language designers prefer to stick with ordinary records. Neverthe- less, Cardelli and Mitchell’s system remains an important conceptual land- mark. An alternative treatment of records based on row-variable polymor- phism has been developed by Wand (1987, 1988, 1989b), Rémy (1990, 1989, 1992), and others, and forms the basis for the object-oriented features of OCaml (Rémy and Vouillon, 1998; Vouillon, 2000). The fundamental problem addressed by a type theory is to insure that pro- grams have meaning. The fundamental problem caused by a type theory is that meaningful programs may not have meanings ascribed to them. The quest for richer type systems results from this tension. —Mark Mannasse 16 Metatheory of Subtyping The definition in the previous chapter of the simply typed lambda-calculus with subtyping is not immediately suitable for implementation. Unlike the other calculi we have seen, the rules of this system are not syntax directed— they cannot just be “read from bottom to top” to yield a typechecking algo- rithm. The main culprits are the rules of subsumption (T-Sub) in the typing relation and transitivity (S-Trans) in the subtype relation. The reason T-Sub is problematic is that the term in its conclusion is speci- fied as a bare metavariable t: Γ ` t : S S <: T Γ ` t : T (T-Sub) Every other typing rule specifies a term of some specific form—T-Abs applies only to lambda-abstractions, T-Var only to variables, etc.—while T-Sub can be applied to any kind of term. This means that, if we are given a term t whose type we are trying to calculate, it will always be possible to apply either T-Sub or the other rule whose conclusion matches the shape of t. S-Trans is problematic for the same reason—its conclusion overlaps with the conclusions of all the other rules. S <: U U <: T S <: T (S-Trans) Since S and T are bare metavariables, we can potentially use S-Trans as the final rule in a derivation of any subtyping statement. Thus, a naive “bottom to top” implementation of the subtyping rules would never know whether to try using this rule or whether to try another rule whose more specific conclusion also matches the two types whose membership in the subtype relation we are trying to check. The calculus studied in this chapter is the simply typed lambda-calculus with subtyping (Figure 15-1) and records (15-3). The corresponding OCaml implementation is rcdsub. §16.3 also deals with booleans and conditionals (8-1); the OCaml implementation for this section is joinsub. §16.4 extends the discussions to Bot; the corresponding implementation is bot. 210 16 Metatheory of Subtyping There is one other problem with S-Trans. Both of its premises mention the metavariable U, which does not appear in the conclusion. If we read the rule naively from bottom to top, it says that we should guess a type U and then attempt to show that S <: U and U <: T. Since there are an infinite number of Us that we could guess, this strategy has little hope of success. The S-Refl rule also overlaps the conclusions of the other subtyping rules. This is less severe than the problems with T-Sub and S-Trans: the reflexivity rule has no premises, so if it matches a subtyping statement we are trying to prove, we can succeed immediately. Still, it is another reason why the rules are not syntax directed. The solution to all of these problems is to replace the ordinary (or declar- ative) subtyping and typing relations by two new relations, called the algo- rithmic subtyping and algorithmic typing relations, whose sets of inference rules are syntax directed. We then justify this switch by showing that the original subtyping and typing relations actually coincide with the algorithmic presentations: the statement S <: T is derivable from the algorithmic subtyp- ing rules iff it is derivable from the declarative rules, and a term is typable by the algorithmic typing rules iff it is typable under the declarative rules. We develop the algorithmic subtype relation in §16.1 and the algorithmic typing relation in §16.2. §16.3 addresses the special typechecking problems of multi-branch constructs like if...then...else, which require additional structure (the existence of least upper bounds, or joins, in the subtype rela- tion). §16.4 considers the minimal type Bot. 16.1 Algorithmic Subtyping A crucial element of any implementation of a language with subtyping is an algorithm for checking whether one type is a subtype of another. This subtype checker will be called by the typechecker when, for example, it encounters an application t1 t2 where t1 has type T→U and t2 has type S. Its function is to decide whether the statement S <: T is derivable from the subtyping rules in Figures 15-1 and 15-3. It accomplishes this by checking whether (S,T) belongs to another relation, written ñ̀ S <: T (“S is algorithmically a subtype of T”), which is defined in such a way that membership can be decided simply by following the structure of the types, and which contains the same pairs of types as the ordinary subtype relation. The significant difference between the declarative and algorithmic relations is that the algorithmic relation drops the S-Trans and S-Refl rules. To begin with, we need to reorganize the declarative system a little. As we saw on page 184, we need to use transitivity to “paste together” subtyping 16.1 Algorithmic Subtyping 211 → {} <: Extends 15-1 and 15-3 S <: S (S-Refl) S <: U U <: T S <: T (S-Trans) S <: Top (S-Top) T1 <: S1 S2 <: T2 S1→S2 <: T1→T2 (S-Arrow) {li i∈1..n} ⊆ {kj j∈1..m} kj = li implies Sj <: Ti {kj:Sj j∈1..m} <: {li:Ti i∈1..n} (S-Rcd) Figure 16-1: Subtype relation with records (compact version) derivations for records involving combinations of depth, width, and permu- tation subtyping. Before we can drop S-Trans, we must first add a rule that bundles depth, width, and permutation subtyping into one: {li i∈1..n} ⊆ {kj j∈1..m} kj = li implies Sj <: Ti {kj:Sj j∈1..m} <: {li:Ti i∈1..n} (S-Rcd) 16.1.1 Lemma: If S <: T is derivable from the subtyping rules including S-RcdDepth, S-Rcd-Width, and S-Rcd-Perm (but not S-Rcd), then it can also be derived using S-Rcd (and not S-RcdDepth, S-Rcd-Width, or S-Rcd-Perm), and vice versa. � Proof: Straightforward induction on derivations. � Lemma 16.1.1 justifies eliminating rules S-RcdDepth, S-Rcd-Width, and S-Rcd-Perm in favor of S-Rcd. Figure 16-1 summarizes the resulting system. Next, we show that, in the system of Figure 16-1, the reflexivity and transi- tivity rules are inessential. 16.1.2 Lemma: 1. S <: S can be derived for every type S without using S-Refl. 2. If S <: T is derivable, then it can be derived without using S-Trans. � Proof: Exercise [Recommended, «««]. � 16.1.3 Exercise [«]: If we add the type Bool, how do these properties change? � This brings us to the definition of the algorithmic subtype relation. 16.1.4 Definition: The algorithmic subtyping relation is the least relation on types closed under the rules in Figure 16-2. � 212 16 Metatheory of Subtyping → {} <: Algorithmic subtyping ñ̀ S <: T ñ̀ S <: Top (SA-Top) {li i∈1..n} ⊆ {kj j∈1..m} if kj = li , then ñ̀ Sj <: Ti ñ̀ {kj:Sj j∈1..m} <: {li:Ti i∈1..n} (SA-Rcd) ñ̀ T1 <: S1 ñ̀ S2 <: T2 ñ̀ S1→S2 <: T1→T2 (SA-Arrow) Figure 16-2: Algorithmic subtyping We say that the algorithmic rules are sound because every statement that can be derived from algorithmic rules can also be derived from the declarative rules (the algorithmic rules do not prove anything new), and complete because every statement that can be derived from the declarative rules can also be derived from the algorithmic rules (the algorithmic rules prove everything that could be proved before). 16.1.5 Proposition [Soundness and completeness]: S <: T iff ñ̀ S <: T. � Proof: Each direction proceeds by induction on derivations, using one of the two previous lemmas. � Now the algorithmic rules, being syntax directed, can be read directly as an algorithm for checking the algorithmic subtype relation (and hence also the declarative subtype relation). In a more conventional pseudocode notation, the algorithm looks like this: subtype(S,T) = if T = Top, then true else if S = S1→S2 and T = T1→T2 then subtype(T1,S1) ∧ subtype(S2,T2) else if S = {kj:Sj j∈1..m} and T = {li:Ti i∈1..n} then {li i∈1..n} ⊆ {kj j∈1..m} ∧ for all i there is some j ∈ 1..m with kj = li and subtype(Sj ,Ti) else false. A concrete realization of this algorithm in ML appears in Chapter 17. Finally, we need to verify that the algorithmic subtype relation is total—i.e., that the recursive function subtype derived from the algorithmic rules returns either true or false, for every pair of inputs, after a finite amount of time. 16.2 Algorithmic Typing 213 16.1.6 Proposition [Termination]: If ñ̀ S <: T is derivable, then subtype(S,T) will return true. If not, then subtype(S,T) will return false. � This theorem, together with the soundness and completeness of the al- gorithmic rules, essentially asserts that the subtype function is a decision procedure for the declarative subtype relation. Proof: The first claim is easy to check (by a straightforward induction on a derivation of ñ̀ S <: T). Conversely, it is also easy to check that, if subtype(S,T) returns true, then ñ̀ S <: T. Thus, to establish the second claim, it suffices to show that subtype(S,T) must always return something—i.e., that it cannot di- verge. This we can do by observing that the sum of the sizes of the input pair S and T is always strictly larger than the sum of the sizes of the arguments to any recursive call that that algorithm makes. Since this sum is always positive, an infinite sequence of recursive calls is not possible. � The reader may wonder whether we could have saved ourselves all the work in this section by simply taking the algorithmic definition of the subtype re- lation as the official definition and never even mentioning the declarative version. The answer is a qualified “Yes.” We can certainly take the algorith- mic definition as the official one when defining the calculus, if we prefer. However, this does not actually save much work, because, to show that the typing relation (which depends on the subtype relation) is well-behaved, we will need to know that subtyping is reflexive and transitive, and these proofs involve more or less the same work as we have done here. (On the other hand, language definitions do often adopt an algorithmic presentation of the typing relation. We will see one example of this in Chapter 19.) 16.2 Algorithmic Typing Having gotten the subtype relation under control, we need to do the same with the typing relation. As we saw on page 209, the only non-syntax-directed typing rule is T-Sub, so this is the one we must deal with. As with S-Trans in the previous section, we cannot simply delete the subsumption rule: we must first examine where it plays a critical role in typing and enrich the other typing rules to achieve the same effects in a more syntax-directed way. Clearly, one critical use of subsumption is bridging gaps between the types expected by functions and the actual types of their arguments. A term like (λr:{x:Nat}. r.x) {x=0,y=1} is not typable without subsumption. 214 16 Metatheory of Subtyping Perhaps surprisingly, this is the only situation where subsumption plays a crucial role in typing. In every other case where subsumption is used in a typing proof, the same statement can be proved by a different derivation in which subsumption is “postponed” by moving it down the tree toward the root. To see why this works, it is instructive to experiment a little with typing derivations involving subsumption, taking each typing rule in turn and thinking about how a derivation ending with this rule can be reorganized if one of its immediate subderivations ends with T-Sub. For example, suppose we are given a typing derivation ending with T-Abs, whose immediate subderivation ends with T-Sub. ... Γ , x:S1 ` s2 : S2 ... S2 <: T2 (T-Sub) Γ , x:S1 ` s2 : T2 (T-Abs) Γ ` λx:S1.s2 : S1→T2 Such a derivation can be rearranged so that subsumption is used after the abstraction rule to achieve the same conclusion: . . . Γ , x:S1 ` s2 : S2 (T-Abs) Γ ` λx:S1.s2 : S1→S2 (S-Refl) S1 <: S1 . . . S2 <: T2 (S-Arrow) S1→S2 <: S1→T2 (T-Sub) Γ ` λx:S1.s2 : S1→T2 A more interesting case is the application rule T-App. Here there are two subderivations, either of which might end with T-Sub. Consider first the case where subsumption appears at the end of the left-hand subderivation. . . . Γ ` s1 : S11→S12 . . . (S-Arrow) S11→S12 <: T11→T12 (T-Sub) Γ ` s1 : T11→T12 . . . Γ ` s2 : T11 (T-App) Γ ` s1 s2 : T12 From the results in the previous section, we may assume that the final rule in the derivation of S11→S12 <: T11→T12 is neither S-Refl nor S-Trans. Given the form of its conclusion, this rule can then only be S-Arrow. 16.2 Algorithmic Typing 215 . . . Γ ` s1 : S11→S12 . . . T11 <: S11 . . . S12 <: T12 (S-Arrow) S11→S12 <: T11→T12 (T-Sub) Γ ` s1 : T11→T12 . . . Γ ` s2 : T11 (T-App) Γ ` s1 s2 : T12 Rewriting to eliminate the instance of T-Sub has an interesting effect. . . . Γ ` s1 : S11→S12 . . . Γ ` s2 : T11 . . . T11 <: S11 (T-Sub) Γ ` s2 : S11 (T-App) Γ ` s1 s2 : S12 . . . S12 <: T12 (T-Sub) Γ ` s1 s2 : T12 The right-hand subderivation of the original instance of S-Arrow has been pushed down to the bottom of the tree, where a new instance of T-Sub raises the type of the whole application node. On the other hand, the left-hand sub- derivation has been pushed up into the derivation for the argument s2. Suppose instead that the instance of T-Sub that we want to relocate occurs at the end of the right-hand subderivation of an instance of T-App. . . . Γ ` s1 : T11→T12 . . . Γ ` s2 : T2 . . . T2 <: T11 (T-Sub) Γ ` s2 : T11 (T-App) Γ ` s1 s2 : T12 The only thing we can do with this instance of T-Sub is to move it over into the left-hand subderivation—partly reversing the previous transformation. . . . Γ ` s1 : T11→T12 . . . T2 <: T11 (S-Refl) T12 <: T12 (S-Arrow) T11→T12 <: T2→T12 (T-Sub) Γ ` s1 : T2→T12 . . . Γ ` s2 : T2 (T-App) Γ ` s1 s2 : T12 So we see that the use of subsumption for promoting the result type of an application can be moved down past the T-App rule, but that the use of sub- sumption for matching the argument type and the domain type of the func- tion cannot be eliminated. It can be moved from one premise to the other—we 216 16 Metatheory of Subtyping can promote the type of the argument to match the domain of the function, or we can promote the type of the function (by demoting its argument type) so that it expects an argument of the type we actually plan to give it—but we cannot get rid of the subsumption altogether. This observation corresponds precisely with our intuition that this gap-bridging use of subsumption is es- sential to the power of the system. Another case we have to consider is where the last rule in a derivation is subsumption and its immediate subderivation also ends with subsumption. In this case, the two adjacent uses of subsumption can be coalesced into one—i.e., any derivation of the form . . . Γ ` s : S . . . S <: U (T-Sub) Γ ` s : U . . . U <: T (T-Sub) Γ ` s : T can be rewritten: . . . Γ ` s : S . . . S <: U . . . U <: T (S-Trans) S <: T (T-Sub) Γ ` s : T 16.2.1 Exercise [« 3]: To finish the experiment, show how to perform similar rear- rangements on derivations in which T-Sub is used before T-Rcd or T-Proj. � By applying these transformations repeatedly, we can rewrite an arbitrary typing derivation into a special form where T-Sub appears in only two places: at the end of right-hand subderivations of applications, and at the very end of the whole derivation. Moreover, if we simply delete the one at the very end, no great harm will result: we will still have a derivation assigning a type to the same term—the only difference is that the type assigned to this term may be a smaller (i.e., better!) one. This leaves just one place, applications, where uses of subsumption can still occur. To deal with this case, we can replace the application rule by a slightly more powerful one Γ ` t1 : T11→T12 Γ ` t2 : T2 T2 <: T11 Γ ` t1 t2 : T12 incorporating a single instance of subsumption as a premise. Every subderiva- tion of the form application-preceded-by-subsumption can be replaced by a use of this rule, which leaves us with no uses of T-Sub at all. Moreover, the enriched application rule is syntax directed: the shape of the term in the conclusion prevents it from overlapping with the other rules. 16.2 Algorithmic Typing 217 → {} <: Algorithmic typing Γ ñ̀ t : T x:T ∈ Γ Γ ñ̀ x : T (TA-Var) Γ , x:T1 ñ̀ t2 : T2 Γ ñ̀ λx:T1.t2 : T1→T2 (TA-Abs) Γ ñ̀ t1 : T1 T1 = T11→T12 Γ ñ̀ t2 : T2 ñ̀ T2 <: T11 Γ ñ̀ t1 t2 : T12 (TA-App) for each i Γ ñ̀ ti : Ti Γ ñ̀ {l1=t1 . . .ln=tn} : {l1:T1 . . .ln:Tn} (TA-Rcd) Γ ñ̀ t1 : R1 R1 = {l1:T1 . . .ln:Tn} Γ ñ̀ t1.li : Ti (TA-Proj) Figure 16-3: Algorithmic typing This transformation yields a syntax-directed set of typing rules that assigns types to the same terms as the original typing rules. These rules are summa- rized in the following definition. As we did for the algorithmic subtyping rules, we write the algorithmic relation with a funny turnstile, Γ ñ̀ t : T, to distinguish it from the declarative relation. 16.2.2 Definition: The algorithmic typing relation is the least relation closed un- der the rules in Figure 16-3. The premise T1 = T11→T12 in the application rule is simply an explicit reminder of the sequencing of operations during type- checking: first we calculate a type T1 for t1; then we check that T1 has the form T11→T12, etc. The rule would have exactly the same force if we dropped this premise and instead wrote the first premise as Γ ñ̀ t1 : T11→T12. Simi- larly for TA-Proj. Also, the subtyping premise in the application rule is writ- ten with a funny turnstile; since we know that the algorithmic and declarative presentations of subtyping are equivalent, this choice is a matter of taste. � 16.2.3 Exercise [« 3]: Show that the type assigned to a term by the algorithmic rules can decrease during evaluation by finding two terms s and t with algo- rithmic types S and T such that s -→ ∗ t and T <: S, but S 6<: T. � We now need to check formally that the algorithmic typing rules corre- spond to the original declarative rules. (The transformations on typing deriva- tions that we enumerated above are too informal to be considered a proof. They could be turned into one, but it would be longer and heavier than nec- essary: it is simpler just to argue by induction on derivations, as usual.) As 218 16 Metatheory of Subtyping we did for subtyping, we argue that the algorithmic typing relation is both sound and complete with respect to the original declarative rules. The soundness property is unchanged: every typing statement that can be derived from the algorithmic rules also follows from the declarative rules. 16.2.4 Theorem [Soundness]: If Γ ñ̀ t : T, then Γ ` t : T. � Proof: Straightforward induction on algorithmic typing derivations. � Completeness, though, looks a little different. The ordinary typing relation can be used to assign many types to a term, while the algorithmic typing relation assigns at most one (as can easily be checked). So a straightforward converse of Theorem 16.2.4 is clearly not going to hold. Instead, we can show that if a term t has a type T under the ordinary typing rules, then it has a better type S under the algorithmic rules, in the sense that S <: T. In other words, the algorithmic rules assign each typable term its smallest possible (minimal) type. The completeness theorem is often called the Minimal Typing theorem, since (when combined with Theorem 16.2.4) it amounts to showing that each typable term in the declarative system has a minimal type. 16.2.5 Theorem [Completeness, or Minimal Typing]: If Γ ` t : T, then Γ ñ̀ t : S for some S <: T. � Proof: Exercise [Recommended, ««]. � 16.2.6 Exercise [««]: If we dropped the arrow subtyping rule S-Arrow but kept the rest of the declarative subtyping and typing rules the same, would the system still have the minimal typing property? If so, prove it. If not, give an example of a typable term with no minimal type. � 16.3 Joins and Meets Typechecking expressions with multiple result branches, such as conditionals or case expressions, in a language with subtyping requires some additional machinery. For example, recall the declarative typing rule for conditionals. Γ `t1 : Bool Γ `t2 : T Γ `t3 : T Γ `if t1 then t2 else t3 : T (T-If) The rule requires that the types of the two branches be the same, and assigns this type to the whole conditional. But in the presence of subsumption, there may be many ways of giving the two branches the same type. For example, if true then {x=true,y=false} else {x=false,z=true}; 16.3 Joins and Meets 219 has type {x:Bool}, since the then part has minimal type {x:Bool,y:Bool}, which can be promoted to {x:Bool} using T-Sub, and similarly the else part has minimal type {x:Bool,z:Bool}, which can also be promoted to {x:Bool}. The same term also has types {x:Top} and {}—in fact, any type that is a supertype of both {x:Bool,y:Bool} and {x:Bool,z:Bool}. The minimal type for the whole conditional is therefore the least type that is a supertype of both {x:Bool,y:Bool} and {x:Bool,z:Bool}—i.e., {x:Bool}. In general, to calculate the minimal type of an arbitrary conditional expres- sion, we need to calculate the minimal types of its then and else branches and then calculate the least common supertype of these. This type is often called the join of the types of the branches, since it corresponds to the usual join of two elements of a partial order. 16.3.1 Definition: A type J is called a join of a pair of types S and T, written S ∨ T = J, if S <: J, T <: J, and, for all types U, if S <: U and T <: U, then J <: U. Similarly, we say that a type M is a meet of S and T, written S ∧ T = M, if M <: S, M <: T, and, for all types L, if L <: S and L <: T, then L <: M. � Depending on how the subtype relation in a particular language with sub- typing is defined, it may or may not be the case that every pair of types has a join. A given subtype relation is said to have joins if, for every S and T, there is some J that is a join of S and T. Similarly, a subtype relation is said to have meets if, for every S and T, there is some M that is a meet of S and T. The subtype relation that we are considering in this section1 has joins, but not meets. For example, the types {} and Top→Top do not have any common subtypes at all, so they certainly have no greatest one. However, a slightly weaker property does hold. A pair of types S and T is said to be bounded below if there is some type L such that L <: S and L <: T. A given subtype relation is said to have bounded meets if, for every S and T such that S and T are bounded below, there is some M that is a meet of S and T. Joins and meets need not be unique. For example, {x:Top,y:Top} and {y:Top,x:Top} are both joins of the pair of types {x:Top,y:Top,z:Top} and {x:Top,y:Top,w:Top}. However, two different joins (or meets) of the same pair of types must each be a subtype of the other. 16.3.2 Proposition [Existence of joins and bounded meets]: 1. For every pair of types S and T, there is some type J such that S ∨ T = J. 1. That is, the relation defined in Figures 15-1 and 15-3, extended with the type Bool. The subtyping behavior of Bool is simple: no rules for it are added to the declarative subtype relation, so its only supertype is Top. 220 16 Metatheory of Subtyping 2. For every pair of types S and T with a common subtype, there is some type M such that S ∧ T = M. � Proof: Exercise [Recommended, «««]. � Using the join operation we can now give an algorithmic rule for the if construct in the presence of subtyping. Γ `t1 : T1 T1 = Bool Γ `t2 : T2 Γ `t3 : T3 T2 ∨ T3 = T Γ `if t1 then t2 else t3 : T (TA-If) 16.3.3 Exercise [««]: What is the minimal type of if true then false else {}? Is this what we want? � 16.3.4 Exercise [«««]: Is it easy to extend the algorithms for calculating joins and meets to an imperative language with references, as described in §15-5? What about the treatment of references in §15.5, where we refine the invariant Ref with covariant Source and contravariant Sink? � 16.4 Algorithmic Typing and the Bottom Type If a minimal type Bot (§15.4) is added to the subtype relation, the subtyping and typing algorithms must be extended a little. We add one rule (the obvious one) to the algorithmic subtype relation ñ̀ Bot <: T (SA-Bot) and two slightly trickier ones to the algorithmic typing relation: Γ ñ̀ t1 : T1 T1 = Bot Γ ñ̀ t2 : T2 Γ ñ̀ t1 t2 : Bot (TA-AppBot) Γ ñ̀ t1 : R1 R1 = Bot Γ ñ̀ t1.li : Bot (TA-ProjBot) The subtyping rule is clear. The intuition behind the typing rules is that, in the declarative system, we can apply something of type Bot to an argument of absolutely any type (by using subsumption to promote the Bot to whatever function type we like), and assume that the result has any other type, and similarly for projection. 16.4.1 Exercise [«]: Suppose we also have conditionals in the language. Do we need to add another algorithmic typing rule for if? � The additions needed to support Bot in this language are not overly com- plicated. We will see in §28.8, though, that more serious complications arise when Bot is combined with bounded quantification. 17 An ML Implementation of Subtyping This chapter extends the OCaml implementation of the simply typed lambda- calculus developed in Chapter 10 with the extra mechanisms needed to sup- port subtyping—in particular, a function for checking the subtype relation. 17.1 Syntax The datatype definitions for types and terms follow the abstract syntax in Figures 15-1 and 15-3. type ty = TyRecord of (string * ty) list | TyTop | TyArr of ty * ty type term = TmRecord of info * (string * term) list | TmProj of info * term * string | TmVar of info * int * int | TmAbs of info * string * ty * term | TmApp of info * term * term The new constructors, compared with the pure simply typed lambda-calculus, are the type TyTop, the type constructor TyRecord, and the term constructors TmRecord and TmProj. We represent records and their types in the simplest possible way, as a list of field names and associated terms or types. 17.2 Subtyping The pseudocode presentation of the algorithmic subtype relation on page 212 can be translated directly into OCaml as follows. 222 17 An ML Implementation of Subtyping let rec subtype tyS tyT = (=) tyS tyT || match (tyS,tyT) with (TyRecord(fS), TyRecord(fT)) → List.for_all (fun (li,tyTi) → try let tySi = List.assoc li fS in subtype tySi tyTi with Not_found → false) fT | (_,TyTop) → true | (TyArr(tyS1,tyS2),TyArr(tyT1,tyT2)) → (subtype tyT1 tyS1) && (subtype tyS2 tyT2) | (_,_) → false We have made one slight change to the algorithm from the pseudocode pre- sentation, adding a reflexivity check at the beginning. (The (=) operator is ordinary equality; it is written in prefix position here because, in some of the other subtyping implementations, it is replaced by a call to a different comparison function. The || operator is a short-circuiting boolean or: if the first branch yields true, the second is never evaluated.) Strictly speaking, this check is not needed. However, it is actually an important optimization in real compilers. In the majority of real-world programs, subtyping is used quite rarely—that is, most times when the subtype checker is called, the two types being compared are actually equal. Moreover, if types are represented so that structurally isomorphic types are guaranteed to have physically iden- tical representations—for example, using hash consing (Goto, 1974; Appel and Gonçalves, 1993) when constructing types—then this check is just one instruction. The subtyping rule for records naturally involves a certain amount of fuss- ing around with lists. List.for_all applies a predicate (its first argument) to every member of a list and returns true iff all these applications return true. List.assoc li fS looks up the label li in the list of fields fS and re- turns the associated field type tySi; if li is not among the labels in fS, it raises Not_found, which we catch and convert into a false response. 17.3 Typing The typechecking function is a straightforward extension of the typeof func- tion from earlier implementations. The main change is the application clause, 17.3 Typing 223 where we perform a subtype check between the argument type and the type expected by the function. We also add two new clauses for record construc- tion and projection. let rec typeof ctx t = match t with TmRecord(fi, fields) → let fieldtys = List.map (fun (li,ti) → (li, typeof ctx ti)) fields in TyRecord(fieldtys) | TmProj(fi, t1, l) → (match (typeof ctx t1) with TyRecord(fieldtys) → (try List.assoc l fieldtys with Not_found → error fi ("label "^l^" not found")) | _ → error fi "Expected record type") | TmVar(fi,i,_) → getTypeFromContext fi ctx i | TmAbs(fi,x,tyT1,t2) → let ctx’ = addbinding ctx x (VarBind(tyT1)) in let tyT2 = typeof ctx’ t2 in TyArr(tyT1, tyT2) | TmApp(fi,t1,t2) → let tyT1 = typeof ctx t1 in let tyT2 = typeof ctx t2 in (match tyT1 with TyArr(tyT11,tyT12) → if subtype tyT2 tyT11 then tyT12 else error fi "parameter type mismatch" | _ → error fi "arrow type expected") The record clauses introduce a few features of OCaml that we have not seen before. In the TmRecord clause, we calculate the list of field names and types fieldtys from the list of names and terms fields by using List.map to apply the function fun (li,ti) → (li, typeof ctx ti) to each name/term pair in turn. In the TmProj clause, we use List.assoc again to look up the type of the selected field; if it raises Not_found, we raise our own error message (^ is string concatenation). 17.3.1 Exercise [«««]: §16.3 showed how adding booleans and conditionals to a language with subtyping required extra support functions for calculating the least upper bounds of a given pair of types. The proof of Proposition 16.3.2 (see page 522) gave mathematical descriptions of the necessary algorithms. 224 17 An ML Implementation of Subtyping The joinexercise typechecker is an incomplete implementation of the simply typed lambda-calculus with subtyping, records, and conditionals: ba- sic parsing and printing functions are provided, but the clause for TmIf is missing from the typeof function, as is the join function on which it de- pends. Add booleans and conditionals (and joins and meets) to this imple- mentation. � 17.3.2 Exercise [««]: Add a minimal Bot type to the rcdsub implementation, fol- lowing the description in §16.4. � 17.3.3 Exercise [««« 3]: If the subtype check in the application rule fails, the error message that our typechecker prints may not be very helpful to the user. We can improve it by including the expected parameter type and the actual argument type in the error message, but even this may be hard to understand. For example, if the expected type is {x:{},y:{},z:{},a:{},b:{},c:{},d:{},e:{},f:{},g:{}} and the actual type is {y:{},z:{},f:{},a:{},x:{},i:{},b:{},e:{},g:{},c:{},h:{}} it is not immediately obvious that what’s missing from the second type is a d field. Error reporting can be greatly improved by changing the subtype function so that, instead of returning true or false, it either returns a trivial value (the unit value ()) or else raises an exception. Since the exception is raised at the point in the types where something actually failed to match, it can be more precise about what the problem was. Notice that this change doesn’t affect the “end-to-end” behavior of the checker: if the subtype checker returns false, the typechecker is always going to raise an exception (by calling error) anyway at that point. Reimplement the typeof and subtype functions to make all of the error messages as informative as possible. � 17.3.4 Exercise [««« 3]: In §15.6 we defined a coercion semantics for a language with records and subtyping using a translation from typing and subtyping derivations into terms of the pure simply typed lambda-calculus. Implement these transformations by modifying the subtype function presented above so that it constructs and returns a coercion function (represented as a term), and similarly modifying the typeof function so that it returns both a type and a translated term. The translated term (rather than the original input term) should then be evaluated, and the result printed as usual. � 18 Case Study: Imperative Objects In this chapter we come to our first substantial programming example. We will use most of the features we have defined—functions, records, general recursion, mutable references, and subtyping—to build up a collection of programming idioms supporting objects and classes similar to those found in object-oriented languages like Smalltalk and Java. We will not introduce any new concrete syntax for objects or classes in this chapter: what we’re after here is to try to understand these rather complex language features by showing how to approximate their behavior using lower-level constructs. For most of the chapter, the approximation is actually quite accurate: we can obtain a satisfactory implementation of most features of objects and classes by regarding them as derived forms that are desugared into sim- ple combinations of features we have already seen. When we get to virtual methods and self in §18.9, however, we will encounter some difficulties with evaluation order that make the desugaring a little unrealistic. A more satisfac- tory account of these features can be obtained by axiomatizing their syntax, operational semantics, and typing rules directly, as we do in Chapter 19. 18.1 What Is Object-Oriented Programming? Most arguments about “What is the essence of. . .?” do more to reveal the prejudices of the participants than to uncover any objective truth about the topic of discussion. Attempts to define the term “object-oriented” precisely are no exception. Nonetheless, we can identify a few fundamental features that are found in most object-oriented languages and that, in concert, sup- port a distinctive programming style with well-understood advantages and disadvantages. The examples in this chapter are terms of the simply typed lambda-calculus with subtyping (Figure 15-1), records (15-3), and references (13-1). The associated OCaml implementation is fullref. 226 18 Case Study: Imperative Objects 1. Multiple representations. Perhaps the most basic characteristic of the object-oriented style is that, when an operation is invoked on an object, the object itself determines what code gets executed. Two objects responding to the same set of operations (i.e., with the same interface) may use entirely different representations, as long as each carries with it an implementation of the operations that works with its particular representation. These im- plementations are called the object’s methods. Invoking an operation on an object—called method invocation or, more colorfully, sending it a mes- sage—involves looking up the operation’s name at run time in a method table associated with the object, a process called dynamic dispatch. By contrast, a conventional abstract data type (ADT) consists of a set of values plus a single implementation of the operations on these values. (This static definition of implementations has both advantages and disad- vantages over objects; we explore these further in §24.2.) 2. Encapsulation. The internal representation of an object is generally hid- den from view outside of the object’s definition: only the object’s own methods can directly inspect or manipulate its fields.1 This means that changes to the internal representation of an object can affect only a small, easily identifiable region of the program; this constraint greatly improves the readability and maintainability of large systems. Abstract data types offer a similar form of encapsulation, ensuring that the concrete representation of their values is visible only within a certain scope (e.g., a module, or an ADT definition), and that code outside of this 1. In some object-oriented languages, such as Smalltalk, this encapsulation is mandatory—the internal fields of an object simply cannot be named outside of its definition. Other languages, such as and , allow fields to be marked either public or private. Conversely, all the meth- ods of an object are publicly accessible in Smalltalk, while Java and C++ allow methods to be marked private, restricting their call sites to other methods in the same object. We will ig- nore such refinements here, but they have been considered in detail in the research literature (Pierce and Turner, 1993; Fisher and Mitchell, 1998; Fisher, 1996a; Fisher and Mitchell, 1996; Fisher, 1996b; Fisher and Reppy, 1999). Although most object-oriented languages take encapsulation as an essential notion, there are several that do not. The multi-methods found in CLOS (Bobrow, DeMichiel, Gabriel, Keene, Kiczales, and Moon, 1988; Kiczales, des Rivières, and Bobrow, 1991), Cecil (Chambers, 1992, 1993), Dylan (Feinberg, Keene, Mathews, and Withington., 1997; Shalit), and KEA (Mugridge, Hamer, and Hosking, 1991) and in the lambda-& calculus of Castagna, Ghelli, and Longo (1995; Castagna, 1997) keep object states separate from methods, using special type-tags to select appropriate alternatives from overloaded method bodies at method invocation time. The un- derlying mechanisms for object creation, method invocation, class definition, etc., in these languages are fundamentally different from the ones we describe in this chapter, although the high-level programming idioms that they lead to are quite similar. 18.1 What Is Object-Oriented Programming? 227 scope can manipulate these values only by invoking operations defined within this privileged scope. 3. Subtyping. The type of an object—its interface—is just the set of names and types of its operations. The object’s internal representation does not appear in its type, since it does not affect the set of things that we can directly do with the object. Object interfaces fit naturally into the subtype relation. If an object satis- fies an interface I, then it clearly also satisfies any interface J that lists fewer operations than I, since any context that expects a J-object can in- voke only J-operations on it and so providing an I-object should always be safe. (Thus, object subtyping is similar to record subtyping. Indeed, for the model of objects developed in this chapter, they will be the same thing.) The ability to ignore parts of an object’s interface allows us to write a single piece of code that manipulates many different sorts of objects in a uniform way, demanding only a certain common set of operations. 4. Inheritance. Objects that share parts of their interfaces will also often share some behaviors, and we would like to implement these common behaviors just once. Most object-oriented languages achieve this reuse of behaviors via structures called classes—templates from which objects can be instantiated—and a mechanism of subclassing that allows new classes to be derived from old ones by adding implementations for new methods and, when necessary, selectively overriding implementations of old meth- ods. (Instead of classes, some object-oriented languages use a mechanism called delegation, which combines the features of objects and classes.) 5. Open recursion. Another handy feature offered by most languages with objects and classes is the ability for one method body to invoke another method of the same object via a special variable called self or, in some languages, this. The special behavior of self is that it is late-bound, al- lowing a method defined in one class to invoke another method that is defined later, in some subclass of the first. The remaining sections of this chapter develop these features in succession, beginning with very simple “stand-alone” objects and then considering in- creasingly powerful forms of classes. Later chapters examine different accounts of objects and classes. Chap- ter 19 presents a direct treatment (not an encoding) of objects and classes in the style of Java. Chapter 27 returns to the encoding developed in the present chapter, improving the run-time efficiency of class construction us- ing bounded quantification. Chapter 32 develops a more ambitious version of the encoding that works in a purely functional setting. 228 18 Case Study: Imperative Objects 18.2 Objects In its simplest form, an object is just a data structure encapsulating some internal state and offering access to this state to clients via a collection of methods. The internal state is typically organized as a number of mutable instance variables (or fields) that are shared among the methods and inacces- sible to the rest of the program. Our running example throughout the chapter will be objects representing simple counters. Each counter object holds a single number and provides two methods (i.e., responds to two messages)—get, which causes it to return its current value; and inc, which increments the value. A straightforward way of obtaining this behavior using the features we have discussed in previous chapters is to use a reference cell for the object’s internal state and a record of functions for the methods. A counter object whose current state is 1 looks like this: c = let x = ref 1 in {get = λ_:Unit. !x, inc = λ_:Unit. x:=succ(!x)}; ñ c : {get:Unit→Nat, inc:Unit→Unit} The method bodies are both written as functions with trivial parameters (writ- ten _ because we don’t need to refer to them in the bodies). The abstractions block evaluation of the method bodies when the object is created, allowing the bodies to be evaluated repeatedly, later, by applying them over and over to the unit argument. Also, note how the state of this object is shared among the methods and inaccessible to the rest of the program: the encapsulation of the state arises directly from the lexical scope of the variable x. To invoke a method of the object c, we just extract a field of the record and apply it to an appropriate argument. For example: c.inc unit; ñ unit : Unit c.get unit; ñ 2 : Nat (c.inc unit; c.inc unit; c.get unit); ñ 4 : Nat The fact that the inc method returns unit allows us to use the ;-notation (§11.3) for sequences of increments. We could equivalently have written the last line above as: 18.3 Object Generators 229 let _ = c.inc unit in let _ = c.inc unit in c.get unit; Since we may want to create and manipulate many counters, it is conve- nient to introduce an abbreviation for their type: Counter = {get:Unit→Nat, inc:Unit→Unit}; Our attention in this chapter is focused on how objects are built, rather than on how they are used in organizing larger programs. However, we do want to see at least one function that uses objects, so that we can verify that it works on objects with different internal representations. Here is a trivial one—a function that takes a counter object and invokes its inc method three times: inc3 = λc:Counter. (c.inc unit; c.inc unit; c.inc unit); ñ inc3 : Counter → Unit (inc3 c; c.get unit); ñ 7 : Nat 18.3 Object Generators We have seen how to build individual counter objects, one at a time. It is equally easy to write a counter generator—a function that creates and returns a new counter every time it is called. newCounter = λ_:Unit. let x = ref 1 in {get = λ_:Unit. !x, inc = λ_:Unit. x:=succ(!x)}; ñ newCounter : Unit → Counter 18.4 Subtyping One of the reasons for the popularity of object-oriented programming styles is that they permit objects of many shapes to be manipulated by the same client code. For example, suppose that, in addition to the Counter objects defined above, we also create some objects with an additional method that allows them to be reset to their initial state (say, 1) at any time. ResetCounter = {get:Unit→Nat, inc:Unit→Unit, reset:Unit→Unit}; 230 18 Case Study: Imperative Objects newResetCounter = λ_:Unit. let x = ref 1 in {get = λ_:Unit. !x, inc = λ_:Unit. x:=succ(!x), reset = λ_:Unit. x:=1}; ñ newResetCounter : Unit → ResetCounter Since ResetCounter has all the fields of Counter (plus one more), the record subtyping rule tells us that ResetCounter <: Counter. This means that client functions like inc3 that take counters as arguments can also safely be used with reset counters: rc = newResetCounter unit; ñ rc : ResetCounter (inc3 rc; rc.reset unit; inc3 rc; rc.get unit); ñ 4 : Nat 18.5 Grouping Instance Variables So far, the states of our objects have consisted of just a single reference cell. Obviously, more interesting objects will often have several instance variables. In the sections that follow, it will be useful to be able to manipulate all of these instance variables as a single unit. To allow for this, let’s change the internal representation of our counters to be a record of reference cells, and refer to instance variables in method bodies by projecting fields from this record. c = let r = {x=ref 1} in {get = λ_:Unit. !(r.x), inc = λ_:Unit. r.x:=succ(!(r.x))}; ñ c : Counter The type of this record of instance variables is called the representation type of the object. CounterRep = {x: Ref Nat}; 18.6 Simple Classes 231 18.6 Simple Classes The definitions of newCounter and newResetCounter are identical except for the reset method in the latter. Of course, both of these definitions are so short anyway that this makes little difference, but if we imagine them stretching over many pages, as can easily happen in practice, it is clear that we would prefer to have some means for describing the common functionality in one place. The mechanism by which this is achieved in most object-oriented languages is called classes. The class mechanisms in real-world object-oriented languages tend to be complex and loaded with features—self, super, visibility annotations, static fields and methods, inner classes, friend classes, annotations such as final and Serializable, etc., etc.2 We’ll ignore most of these here and focus our attention on the most basic aspects of classes: code reuse via inheritance, and the late binding of self. For the moment, let’s consider just the former. In its most primitive form, a class is simply a data structure holding a collection of methods that can either be instantiated to yield a fresh object or extended to yield another class. Why can’t we just reuse the methods from some counter object to build a reset counter? Simply because, in any particular counter object, the method bodies contain references to some particular record of instance variables. Clearly, if we want to be able to reuse the same code with a different record of instance variables, what we need to do is to abstract the methods with respect to the instance variables. This amounts to breaking our newCounter function above into two pieces, one that defines the method bodies with respect to an arbitrary record of instance variables, counterClass = λr:CounterRep. {get = λ_:Unit. !(r.x), inc = λ_:Unit. r.x:=succ(!(r.x))}; ñ counterClass : CounterRep → Counter and one that allocates a record of instance variables and supplies it to the method bodies to create an object: newCounter = λ_:Unit. let r = {x=ref 1} in counterClass r; 2. The main reason for all this complexity is that, in most of these languages, classes are the only large-scale structuring mechanism. Indeed, there is just one widely used language— OCaml—that provides both classes and a sophisticated module system. So classes in most languages tend to become the dumping ground for all language features that have anything to do with large-scale program structure. 232 18 Case Study: Imperative Objects ñ newCounter : Unit → Counter The method bodies from counterClass can be reused to define new classes, called subclasses. For example, we can define a class of reset counters: resetCounterClass = λr:CounterRep. let super = counterClass r in {get = super.get, inc = super.inc, reset = λ_:Unit. r.x:=1}; ñ resetCounterClass : CounterRep → ResetCounter Like counterClass, this function takes a record of instance variables and returns an object. Internally, it works by first using counterClass to create a counter object with the same record of instance variables r; this “parent object” is bound to the variable super. It then builds a new object by copying the get and inc fields from super and supplying a new function as the value for the reset field. Since super was built on r, all three methods share the same instance variables. To build a reset counter object, we again just allocate memory for its in- stance variables and call resetCounterClass, where the real work happens. newResetCounter = λ_:Unit. let r = {x=ref 1} in resetCounterClass r; ñ newResetCounter : Unit → ResetCounter 18.6.1 Exercise [Recommended, ««]: Write a subclass of resetCounterClass with an additional method dec that subtracts one from the current value stored in the counter. Use the fullref checker to test your new class. � 18.6.2 Exercise [«« 3]: The explicit copying of most of the superclass fields into the record of subclass methods is notationally rather clumsy—it avoids ex- plicitly re-entering the code of superclass methods in subclasses, but it still involves a lot of typing. If we were going to develop larger object-oriented programs in this style, we would soon wish for a more compact notation like “super with {reset = λ_:Unit. r.x:=1},” meaning “a record just like super but with a field reset containing the function λ_:Unit. r.x:=1.” Write out syntax, operational semantics, and typing rules for this construct. � We should emphasize that these classes are values, not types. Also we can, if we like, create many classes that generate objects of exactly the same type. In mainstream object-oriented languages like C++ and , classes have a more complex status—they are used both as compile-time types and as run-time data structures. This point is discussed further in §19.3. 18.7 Adding Instance Variables 233 18.7 Adding Instance Variables It happens that our counter and reset counter objects use exactly the same internal representation. However, in general a subclass may need to extend not only the methods but also the instance variables of the superclass from which it is derived. For example, suppose we want to define a class of “backup counters” whose reset method resets their state to whatever value it has when we last called the method backup, instead of resetting it to a constant value: BackupCounter = {get:Unit→Nat, inc:Unit→Unit, reset:Unit→Unit, backup: Unit→Unit}; To implement backup counters, we need an extra instance variable to store the backed-up value of the state. BackupCounterRep = {x: Ref Nat, b: Ref Nat}; Just as we derived resetCounterClass from counterClass by copying the get and inc methods and adding reset, we derive backupCounterClass from resetCounterClass by copying get and inc and providing reset and backup. backupCounterClass = λr:BackupCounterRep. let super = resetCounterClass r in {get = super.get, inc = super.inc, reset = λ_:Unit. r.x:=!(r.b), backup = λ_:Unit. r.b:=!(r.x)}; ñ backupCounterClass : BackupCounterRep → BackupCounter Two things are interesting about this definition. First, although the parent object super includes a method reset, we chose to write a fresh implemen- tation because we wanted a different behavior. The new class overrides the reset method of the superclass. Second, subtyping is used in an essential way here in typing the expression that builds super: resetCounterClass expects an argument of type CounterRep, which is a supertype of the actual type, BackupCounterRep, of the argument r. In other words, we are actually providing the parent object with a larger record of instance variables than its methods require. 18.7.1 Exercise [Recommended, ««]: Define a subclass of backupCounterClass with two new methods, reset2 and backup2, controlling a second “backup 234 18 Case Study: Imperative Objects register.” This register should be completely separate from the one added by backupCounterClass: calling reset should restore the counter to its value at the time of the last call to backup (as it does now) and calling reset2 should restore the counter to its value at the time of the last call to backup2. Use the fullref checker to test your class. � 18.8 Calling Superclass Methods The variable super has been used to copy functionality from superclasses into new subclasses. We can also use super in the bodies of method defi- nitions to extend the superclass’s behavior with something extra. Suppose, for instance, that we want a variant of our backupCounter class in which every call to the inc method is automatically preceded by a call to backup. (Goodness knows why such a class would be useful—it’s just an example.) funnyBackupCounterClass = λr:BackupCounterRep. let super = backupCounterClass r in {get = super.get, inc = λ_:Unit. (super.backup unit; super.inc unit), reset = super.reset, backup = super.backup}; ñ funnyBackupCounterClass : BackupCounterRep → BackupCounter Note how the calls to super.inc and super.backup in the new definition of inc avoid repeating the superclass’s code for inc or backup here. In larger examples, the savings of duplicated functionality in such situations can be substantial. 18.9 Classes with Self Our final extension is allowing the methods of classes to refer to each other via self. To motivate this extension, suppose that we want to implement a class of counters with a set method that can be used from the outside to set the current count to a particular number. SetCounter = {get:Unit→Nat, set:Nat→Unit, inc:Unit→Unit}; Moreover, suppose that we want the inc method in terms of set and get, rather than directly reading and assigning the instance variable x. (Imagine a much larger example in which the definitions of set and get each take many 18.10 Open Recursion through Self 235 pages.) Since get, set, and inc are all defined in the same class, what we are asking for is essentially to make the methods of this class mutually recursive. We saw how to build mutually recursive records of functions using the fix operator in §11.11. We simply abstract the record of methods on a parameter that is itself a record of functions (which we call self), and then use the fix operator to “tie the knot,” arranging that the very record we are constructing is the one passed as self. setCounterClass = λr:CounterRep. fix (λself: SetCounter. {get = λ_:Unit. !(r.x), set = λi:Nat. r.x:=i, inc = λ_:Unit. self.set (succ (self.get unit))}); ñ setCounterClass : CounterRep → SetCounter This class has no parent class, so there is no need for a super variable. Instead, the body of the inc method invokes get and then set from the record of methods passed to it as self. This use of fix is entirely internal to setCounterClass. We then create set-counters in exactly the same way as usual. newSetCounter = λ_:Unit. let r = {x=ref 1} in setCounterClass r; ñ newSetCounter : Unit → SetCounter 18.10 Open Recursion through Self Most object-oriented languages actually support a more general form of re- cursive call between methods, known as open recursion, or late-binding of self. We can achieve this more general behavior by removing the use of fix from the class definition, setCounterClass = λr:CounterRep. λself: SetCounter. {get = λ_:Unit. !(r.x), set = λi:Nat. r.x:=i, inc = λ_:Unit. self.set (succ(self.get unit))}; ñ setCounterClass : CounterRep → SetCounter → SetCounter 236 18 Case Study: Imperative Objects and instead placing it in the object creation function. newSetCounter = λ_:Unit. let r = {x=ref 1} in fix (setCounterClass r); ñ newSetCounter : Unit → SetCounter Notice that moving the use of fix changes the type of setCounterClass: instead of being abstracted just on a record of instance variables, it is also abstracted on a “self-object”; both are supplied at instantiation time. The reason why open recursion through self is interesting is that it allows the methods of a superclass to call the methods of a subclass, even though the subclass does not exist when the superclass is being defined. In effect, we have changed the interpretation of self so that, instead of “the methods of this class,” it provides access to “the methods of the class from which the current object was instantiated [which may be a subclass of this one].” For example, suppose we want to build a subclass of our set-counters that keeps track of how many times the set method has been called. The interface of this class includes one extra operation for extracting the access count, InstrCounter = {get:Unit→Nat, set:Nat→Unit, inc:Unit→Unit, accesses:Unit→Nat}; and the representation includes an instance variable for the access count: InstrCounterRep = {x: Ref Nat, a: Ref Nat}; In the definition of the instrumented counter class, the inc and get methods are copied from the setCounterClass that we defined above. The accesses method is written out in the ordinary way. In the set method, we first incre- ment the access count and then use super to invoke the superclass’s set. instrCounterClass = λr:InstrCounterRep. λself: InstrCounter. let super = setCounterClass r self in {get = super.get, set = λi:Nat. (r.a:=succ(!(r.a)); super.set i), inc = super.inc, accesses = λ_:Unit. !(r.a)}; ñ instrCounterClass : InstrCounterRep → InstrCounter → InstrCounter Because of the open recursion through self, the call to set from the body of inc will result in the instance variable a being incremented, even though the incrementing behavior of set is defined in the subclass and the definition of inc appears in the superclass. 18.11 Open Recursion and Evaluation Order 237 18.11 Open Recursion and Evaluation Order There is one problem with our definition of instrCounterClass—we cannot use it to build instances! If we write newInstrCounter in the usual way newInstrCounter = λ_:Unit. let r = {x=ref 1, a=ref 0} in fix (instrCounterClass r); ñ newInstrCounter : Unit → InstrCounter and then attempt to create an instrumented counter by applying it to unit, ic = newInstrCounter unit; the evaluator will diverge. To see how this happens, consider the sequence of evaluation steps that ensue when we start from this term. 1. We first apply newInstrCounter to unit, yielding let r = {x=ref 1, a=ref 0} in fix (instrCounterClass r) 2. We next allocate two ref cells, package them into a record—let’s call it —and substitute for r in the rest.

fix (instrCounterClass )

3. We pass to instrCounterClass. Since instrCounterClass be-

gins with two lambda-abstractions, we immediately get back a function

that is waiting for self,

fix (λself:InstrCounter.

let super = setCounterClass self in )

where is the record of instrumented-counter methods. Let’s

call this function and write the current state (fix ).

4. We apply the evaluation rule for fix (E-Fix in Figure 11-12, page 144),

which “unfolds” fix by substituting (fix ) for self in the body

of , yielding

let super = setCounterClass (fix ) in

5. We now reduce the application of setCounterClass to , yielding:

let super = (λself:SetCounter. ) (fix )

in

238 18 Case Study: Imperative Objects

where is the record of set-counter methods.

6. By the evaluation rules for applications, we cannot reduce the applica-

tion of (λself:SetCounter. ) to (fix ) until the latter

has been reduced to a value. So the next step of evaluation again unfolds

fix , yielding:

let super = (λself:SetCounter. )

(let super = setCounterClass (fix )

in )

in

7. Since the argument to the outer lambda-abstraction is still not a value,

we must continue to work on evaluating the inner one. We perform the

application of setCounterClass to , yielding

let super = (λself:SetCounter. )

(let super = (λself:SetCounter. )

(fix )

in )

in

8. Now we have created an inner application similar in form to the outer

one. Just as before, this inner application cannot be reduced until its ar-

gument, fix , has been fully evaluated. So our next step is again to

unfold fix , yielding a yet more deeply nested expression of the same

form as in step 6. It should be clear at this point that we are never going

to get around to evaluating the outer application.

Intuitively, the problem here is that the argument to the fix operator is us-

ing its own argument, self, too early. The operational semantics of fix is

defined with the expectation that, when we apply fix to some function λx.t,

the body t should refer to x only in “protected” positions, such as the bodies

of inner lambda-abstractions. For example, we defined iseven on page 143

by applying fix to a function of the form λie. λx. …, where the recursive

reference to ie in the body was protected by the abstraction on x. By con-

trast, the definition of instrCounterClass tries to use self right away in

calculating the value of super.

At this point, we can proceed in several ways:

• We can protect the reference to self in instrCounterClass to prevent it

from being evaluated too early, for example by inserting dummy lambda-

abstractions. We develop this solution below. We will see that it is not com-

pletely satisfactory, but it is straightforward to describe and understand

18.11 Open Recursion and Evaluation Order 239

using the mechanisms we have already seen. We will also find it useful

later, when we consider purely functional object encodings in Chapter 32.

• We can look for different ways of using low-level language features to

model the semantics of classes. For example, instead of using fix to build

the method table of a class, we could build it more explicitly using refer-

ences. We develop this idea in §18.12 and further refine it in Chapter 27.

• We can forget about encoding objects and classes in terms of lambda-

abstraction, records, and fix, and instead take them as language prim-

itives, with their own evaluation (and typing) rules. Then we can simply

choose evaluation rules that match our intentions about how objects and

classes should behave, rather than trying to work around the problems

with the given rules for application and fix. This approach will be devel-

oped in Chapter 19.

Using dummy lambda-abstractions to control evaluation order is a well-

known trick in the functional programming community. The idea is that an

arbitrary expression t can be turned into a function λ_:Unit.t, called a

thunk. This “thunked form” of t is a syntactic value; all the computation

involved in evaluating t is postponed until the thunk is applied to unit. This

gives us a way to pass t around in unevaluated form and, later, ask for its

result.

What we want to do at the moment is to delay the evaluation of self. We

can do this by changing its type from an object (e.g. SetCounter) to an object

thunk (Unit→SetCounter). This involves (1) changing the type of the self

parameter to the class, (2) adding a dummy abstraction before we construct

the result object, and (3) changing every occurrence of self in the method

bodies to (self unit).

setCounterClass =

λr:CounterRep.

λself: Unit→SetCounter.

λ_:Unit.

{get = λ_:Unit. !(r.x),

set = λi:Nat. r.x:=i,

inc = λ_:Unit. (self unit).set(succ((self unit).get unit))};

ñ setCounterClass : CounterRep →

(Unit→SetCounter) → Unit → SetCounter

Since we do not want the type of newSetCounter to change (it should still

return an object), we also need to modify its definition slightly so that it

passes a unit argument to the thunk that results when we form the fixed

point of setCounterClass.

240 18 Case Study: Imperative Objects

newSetCounter =

λ_:Unit. let r = {x=ref 1} in

fix (setCounterClass r) unit;

ñ newSetCounter : Unit → SetCounter

Similar changes are needed in the definition of instrCounterClass. Note

that none of these modifications actually require any thinking: once we have

changed the type of self, every other change is dictated by the typing rules.

instrCounterClass =

λr:InstrCounterRep.

λself: Unit→InstrCounter.

λ_:Unit.

let super = setCounterClass r self unit in

{get = super.get,

set = λi:Nat. (r.a:=succ(!(r.a)); super.set i),

inc = super.inc,

accesses = λ_:Unit. !(r.a)};

ñ instrCounterClass : InstrCounterRep →

(Unit→InstrCounter) → Unit → InstrCounter

Finally, we change newInstrCounter so that it supplies a dummy argument

to the thunk constructed by fix.

newInstrCounter =

λ_:Unit. let r = {x=ref 1, a=ref 0} in

fix (instrCounterClass r) unit;

ñ newInstrCounter : Unit → InstrCounter

We can now use newInstrCounter to actually build an object.

ic = newInstrCounter unit;

ñ ic : InstrCounter

Recall that this was the step that diverged before we added thunks.

The following tests demonstrate how the accesses method counts calls to

both set and inc, as we intended.

(ic.set 5; ic.accesses unit);

ñ 1 : Nat

(ic.inc unit; ic.get unit);

ñ 6 : Nat

18.12 A More Efficient Implementation 241

ic.accesses unit;

ñ 2 : Nat

18.11.1 Exercise [Recommended, «««]: Use the fullref checker to implement the

following extensions to the classes above:

1. Rewrite instrCounterClass so that it also counts calls to get.

2. Extend your modified instrCounterClass with a subclass that adds a

reset method, as in §18.4.

3. Add another subclass that also supports backups, as in §18.7. �

18.12 A More Efficient Implementation

The tests above demonstrate that our implementation of classes matches the

“open recursion” behavior of method calls through self in languages like

Smalltalk, C++, and Java. However, we should note that the implementation

is not entirely satisfactory from the point of view of efficiency. All the thunks

we have inserted to make the fix calculation converge have the effect of

postponing the calculation of the method tables of classes. In particular, note

that all the calls to self inside method bodies have become (self unit)—

that is, the methods of self are being recalculated on the fly every time we

make a recursive call to one of them!

We can avoid all this recalculation by using reference cells instead of fixed

points to “tie the knot” in the class hierarchy when we build objects.3 Instead

of abstracting classes on a record of methods called self that will be con-

structed later using fix, we abstract on a reference to a record of methods,

and allocate this record first. That is, we instantiate a class by first allocating

a heap cell for its methods (initialized with a dummy value), then construct-

ing the real methods (passing them a pointer to this heap cell, which they can

use to make recursive calls), and finally back-patching the cell to contain the

real methods. For example, here is setCounterClass again.

setCounterClass =

λr:CounterRep. λself: Ref SetCounter.

{get = λ_:Unit. !(r.x),

set = λi:Nat. r.x:=i,

inc = λ_:Unit. (!self).set (succ ((!self).get unit))};

3. This is essentially the same idea as we used in the solution to Exercise 13.5.8. I am grateful

to James Riely for the insight that it can be applied to class construction by exploiting the

covariance of Source types.

242 18 Case Study: Imperative Objects

ñ setCounterClass : CounterRep → (Ref SetCounter) → SetCounter

The self parameter is a pointer to the cell that contains the methods of the

current object. When setCounterClass is called, this cell is initialized with

a dummy value:

dummySetCounter =

{get = λ_:Unit. 0,

set = λi:Nat. unit,

inc = λ_:Unit. unit};

ñ dummySetCounter : SetCounter

newSetCounter =

λ_:Unit.

let r = {x=ref 1} in

let cAux = ref dummySetCounter in

(cAux := (setCounterClass r cAux); !cAux);

ñ newSetCounter : Unit → SetCounter

However, since all of the dereference operations (!self) are protected by

lambda-abstractions, the cell will not actually be dereferenced until after it

has been back-patched by newSetCounter.

To support building subclasses of setCounterClass, we need to make

one further refinement in its type. Each class expects its self parameter to

have the same type as the record of methods that it constructs. That is, if

we define a subclass of instrumented counters, then the self parameter of

this class will be a pointer to a record of instrumented counter methods. But,

as we saw in §15.5, the types Ref SetCounter and Ref InstrCounter are

incompatible—it is unsound to promote the latter to the former. This will

lead to trouble (i.e., a parameter type mismatch) when we try to create super

in the definition of instrCounterClass.

instrCounterClass =

λr:InstrCounterRep. λself: Ref InstrCounter.

let super = setCounterClass r self in

{get = super.get,

set = λi:Nat. (r.a:=succ(!(r.a)); super.set i),

inc = super.inc,

accesses = λ_:Unit. !(r.a)};

ñ Error: parameter type mismatch

The way out of this difficulty is to replace the Ref constructor in the type

of self by Source—i.e., to pass to the class just the capability to read from

18.12 A More Efficient Implementation 243

the method pointer, not the capability to write to it (which it does not need

anyway). As we saw in §15.5, Source permits covariant subtyping—i.e., we

have Ref InstrCounter <: Ref SetCounter—so the creation of super in instrCounterClass becomes well typed. setCounterClass = λr:CounterRep. λself: Source SetCounter. {get = λ_:Unit. !(r.x), set = λi:Nat. r.x:=i, inc = λ_:Unit. (!self).set (succ ((!self).get unit))}; ñ setCounterClass : CounterRep → (Source SetCounter) → SetCounter instrCounterClass = λr:InstrCounterRep. λself: Source InstrCounter. let super = setCounterClass r self in {get = super.get, set = λi:Nat. (r.a:=succ(!(r.a)); super.set i), inc = super.inc, accesses = λ_:Unit. !(r.a)}; ñ instrCounterClass : InstrCounterRep → (Source InstrCounter) → InstrCounter To build an instrumented counter object, we first define a dummy collec- tion of instrumented counter methods, as before, to serve as the initial value of the self pointer. dummyInstrCounter = {get = λ_:Unit. 0, set = λi:Nat. unit, inc = λ_:Unit. unit, accesses = λ_:Unit. 0}; ñ dummyInstrCounter : InstrCounter We then create an object by allocating heap space for the instance variables and methods, calling instrCounterClass to construct the actual methods, and back-patching the reference cell. newInstrCounter = λ_:Unit. let r = {x=ref 1, a=ref 0} in let cAux = ref dummyInstrCounter in (cAux := (instrCounterClass r cAux); !cAux); ñ newInstrCounter : Unit → InstrCounter 244 18 Case Study: Imperative Objects The code for constructing the method table (in instrCounterClass and counterClass) is now called once per object creation, rather than once per method invocation. This achieves what we set out to do, but it is still not quite as efficient as we might wish: after all the method table that we construct for each instrumented counter object is always exactly the same, so it would seem we should be able to compute this method table just once, when the class is defined, and never again. We will see in Chapter 27 how this can be accomplished using the bounded quantification introduced in Chapter 26. 18.13 Recap The first section of this chapter listed several characteristic features of the object-oriented programming style. Let us recall these features and briefly discuss how they relate to the examples developed in the chapter. 1. Multiple representations. All of the objects that we have seen in this chap- ter are counters—i.e., they belong to the type Counter. But their represen- tations vary widely, from single reference cells in §18.2 to records con- taining several references in §18.9. Each object is a record of functions, providing implementations of the Counter methods (and perhaps others) appropriate to its own internal representation. 2. Encapsulation. The fact that the instance variables of an object are acces- sible only from its methods follows directly from the way we build objects, building the methods by passing the record of instance variables to a con- structor function. It is obvious that the instance variables can be named only from inside the methods. 3. Subtyping. In this setting, subtyping between object types is just ordinary subtyping between types of records of functions. 4. Inheritance. We modeled inheritance by copying implementations of meth- ods from an existing superclass to a newly defined subclass. There were a few interesting technicalities here: strictly speaking, both the superclass and the new subclass are functions from instance variables to records of methods. The subclass waits for its instance variables, then instantiates the superclass with the instance variables it is given, forming a record of superclass methods operating on the same variables. 5. Open recursion. The open recursion provided by self (or this) in real- world object-oriented languages is modeled here by abstracting classes not only on instance variables but also on a self parameter, which can 18.14 Notes 245 be used in methods to refer to other methods of the same object. This parameter is resolved at object-creation time by using fix to “tie the knot.” 18.13.1 Exercise [«««]: Another feature of objects that is useful for some purposes is a notion of object identity—an operation sameObject that yields true if its two arguments evaluate to the very same object, and false if they eval- uate to objects that were created at different times (by different calls to new functions). How might the model of objects in this chapter be extended to support object identity? � 18.14 Notes Object encodings are a staple source of examples and problems for the pro- gramming languages research community. An early encoding was given by Reynolds (1978); general interest in the area was sparked by an article by Cardelli (1984). The understanding of self in terms of fixed points was de- veloped by Cook (1989), Cook and Palsberg (1989), Kamin (1988), and Reddy (1988); relations between these models were explored by Kamin and Reddy (1994) and Bruce (1991). A number of important early papers in the area are collected in Gunter and Mitchell (1994). Later developments are surveyed by Bruce, Cardelli, and Pierce (1999) and by Abadi and Cardelli (1996). Bruce (2002) gives an up-to- date picture of progress in the area. Alternative foundational approaches to objects and their type systems can be found in Palsberg and Schwartzbach (1994) and Castagna (1997). Some additional historical notes can be found at the end of Chapter 32. Inheritance is highly overrated. —Grady Booch 19 Case Study: Featherweight Java We saw in Chapter 18 how a lambda-calculus with subtyping, records, and references can model certain key features of object-oriented programming. The goal in that chapter was to deepen our understanding of these features by encoding them in terms of more elementary ones. In this chapter, we take a different approach, showing how to adapt the ideas in previous chapters to a direct treatment of a core object-oriented language based on Java. Prior acquaintance with Java is assumed. 19.1 Introduction Formal modeling can offer a significant boost to the design of complex real- world artifacts such as programming languages. A formal model may be used to describe some aspect of a design precisely, to state and prove its proper- ties, and to direct attention to issues that might otherwise be overlooked. In formulating a model, however, there is a tension between completeness and compactness: the more aspects the model addresses at the same time, the more unwieldy it becomes. Often it is sensible to choose a model that is less complete but more compact, offering maximum insight for minimum investment. This strategy may be seen in a flurry of recent papers on the for- mal properties of Java, which omit advanced features such as concurrency and reflection and concentrate on fragments of the full language to which well-understood theory can be applied. Featherweight Java, or FJ, was proposed by Igarashi, Pierce, and Wadler (1999) as a contender for a minimal core calculus for modeling Java’s type system. The design of FJ favors compactness over completeness almost ob- sessively, having just five forms of term: object creation, method invocation, The examples in this chapter are terms of FeatherWeight Java (Figures 19-1 through 19-4). There is no associated OCaml implementation; rather, since FJ is designed to be a strict subset of Java, any Java implementation can be used to run the examples. 248 19 Case Study: Featherweight Java field access, casting, and variables. Its syntax, typing rules, and operational semantics fit comfortably on a single (letter-sized) page. Indeed, the aim of its design was to omit as many features as possible—even assignment—while retaining the core features of Java typing. There is a direct correspondence between FJ and a purely functional core of Java, in the sense that every FJ program is literally an executable Java program. FJ is only a little larger than the lambda-calculus or Abadi and Cardelli’s object calculus (1996), and is significantly smaller than other formal models of class-based languages like Java, including those of Drossopoulou, Eisen- bach, and Khurshid (1999), Syme (1997), Nipkow and Oheimb (1998), and Flatt, Krishnamurthi, and Felleisen (1998a, 1998b). Being smaller, FJ can fo- cus on just a few key issues. For example, we shall see that capturing the behavior of Java’s casting construct in a small-step operational semantics is trickier than we might have expected. FJ’s main application is modeling extensions of Java. Because FJ itself is so compact, it focuses attention on essential aspects of an extension. Moreover, because the proof of type safety for pure FJ is very simple, a rigorous safety proof for even a significant extension may remain manageable. The origi- nal FJ paper illustrated this utility by enriching FJ with generic classes and methods à la GJ (Bracha, Odersky, Stoutamire, and Wadler, 1998). A followup paper (Igarashi, Pierce, and Wadler, 2001) formalized raw types, a feature in- troduced in GJ to ease evolution of Java programs to GJ. Igarashi and Pierce (2000) used FJ as the basis for a study of Java’s inner class features. FJ has also been used for studies of type-preserving compilation (League, Trifonov, and Shao, 2001) and semantic foundations (Studer, 2001) for Java. The goal in designing FJ was to make its proof of type safety as concise as possible, while still capturing the essence of the safety argument for the central features of full Java. Any language feature that made the safety proof longer without making it significantly different was a candidate for omission. Like other studies of its kind, FJ omits advanced features such as concurrency and reflection. Other Java features missing from FJ include assignment, inter- faces, overloading, messages to super, null pointers, base types (int, bool, etc.), abstract method declarations, inner classes, shadowing of superclass fields by subclass fields, access control (public, private, etc.), and excep- tions. The features of Java that FJ does model include mutually recursive class definitions, object creation, field access, method invocation, method override, method recursion through this, subtyping, and casting. A key simplification in FJ is the omission of assignment. We assume that an object’s fields are initialized by its constructor and never changed after- wards. This restricts FJ to a “functional” fragment of Java, in which many common Java idioms, such as use of enumerations, cannot be represented. 19.2 Overview 249 Nonetheless, this fragment is computationally complete (it is easy to encode the lambda-calculus into it), and is large enough to include useful programs— for example, many of the programs in Felleisen and Friedman’s Java text (1998) use a purely functional style. 19.2 Overview In FJ, a program consists of a collection of class definitions plus a term to be evaluated, corresponding to the body of the main method in full Java. Here are some typical class definitions in FJ. class A extends Object { A() { super(); } } class B extends Object { B() { super(); } } class Pair extends Object { Object fst; Object snd; // Constructor: Pair(Object fst, Object snd) { super(); this.fst=fst; this.snd=snd; } // Method definition: Pair setfst(Object newfst) { return new Pair(newfst, this.snd); } } For the sake of syntactic regularity, we always include the superclass (even when it is Object), we always write out the constructor (even for the trivial classes A and B), and we always name the receiver in a field access or a method invocation (as in this.snd), even when the receiver is this. Constructors always take the same stylized form: there is one parameter for each field, with the same name as the field; the super constructor is invoked to initialize the fields of the superclass; and then the remaining fields are initialized to the corresponding parameters. In this example, the superclass of all three classes is Object, which has no fields, so the invocations of super have no arguments. Constructors are the only place where super or = appears in an FJ program. Since FJ provides no side-effecting operations, a method body always consists of return followed by a term, as in the body of setfst(). There are five forms of term in FJ. In the example, new A(), new B(), and new Pair( . . ., . . .) are object constructors, and . . . .setfst( . . .) is a method invocation. In the body of setfst, the term this.snd is a field access, and the occurrences of newfst and this are variables.1 In the context of the above 1. The syntax of FJ differs slightly from Java in treating this as a variable, not a keyword. 250 19 Case Study: Featherweight Java definitions, the term new Pair(new A(), new B()).setfst(new B()) evaluates to new Pair(new B(), new B()). The remaining form of term is a cast (see §15.5). The term ((Pair)new Pair(new Pair(new A(), new B()), new A()).fst).snd evaluates to new B(). The subterm (Pair)t, where t is new Pair( . . .).fst, is a cast. The cast is required, because t is a field access to fst, which is declared to contain an Object, whereas the next field access, to snd, is valid only on a Pair. At run time, the evaluation rules check whether the Object stored in the fst field is a Pair (in this case the check succeeds). Dropping side effects has a pleasant side effect: evaluation can easily be formalized entirely within the syntax of FJ, with no additional mechanisms for modeling the heap (see Chapter 13). There are three basic computation rules: one for field access, one for method invocation, and one for casts. Re- call that, in the lambda-calculus, the evaluation rule for applications assumes that the function is first simplified to a lambda abstraction. Similarly, in FJ the evaluation rules assume the object operated upon is first simplified to a new term. The slogan in the lambda-calculus is “everything is a function”; here, “everything is an object.” The next example shows the rule for field access (E-ProjNew) in action: new Pair(new A(), new B()).snd -→ new B() Because of the stylized syntax of object constructors, we know that the con- structor has one parameter for each field, in the same order that the fields are declared. Here the fields are fst and snd, and an access to the snd field selects the second parameter. Here is the rule for method invocation (E-InvkNew) in action: new Pair(new A(), new B()).setfst(new B()) -→ [ newfst, new B(), this, new Pair(new A(),new B()) ] new Pair(newfst, this.snd) i.e., new Pair(new B(), new Pair(new A(), new B()).snd) The receiver of the invocation is the object new Pair(new A(),new B()), so we look up the setfst method in the Pair class, where we find that it has formal parameter newfst and body new Pair(newfst, this.snd). The invo- cation reduces to the body with the formal parameter replaced by the actual, 19.3 Nominal and Structural Type Systems 251 and the special variable this replaced by the receiver object. This is similar to the beta-reduction rule (E-AppAbs) of the lambda-calculus. The key differ- ences are the fact that the class of the receiver determines where to look for the body (supporting method override), and the substitution of the receiver for this (supporting “open recursion through self”).2 In FJ, as in the lambda- calculus, if the formal parameter appears more than once in the body this may lead to duplication of the argument value, but since there are no side effects this difference from the standard Java semantics cannot be observed. Here is the rule for casts (E-CastNew) in action: (Pair)new Pair(new A(), new B()) -→ new Pair(new A(), new B()) Once the subject of the cast is reduced to an object, it is easy to check that the class of the constructor is a subclass of the target of the cast. If so (as is the case here), the reduction removes the cast. If not, as in the term (A)new B(), then no rule applies and the computation is stuck, denoting a run-time error. There are three ways in which a computation may get stuck: an attempt to access a field not declared for the class, an attempt to invoke a method not declared for the class (“message not understood”), or an attempt to cast to something other than a superclass of an object’s run-time class. We will prove that the first two of these never happen in well-typed programs, and that the third never happens in well-typed programs that contain no downcasts (and no “stupid casts”—a technicality explained below). We adopt a standard call-by-value evaluation strategy. Here are the steps of evaluation for the second example term above, where the next subterm to be reduced is underlined at each step. ((Pair) (new Pair(new Pair(new A(),new B()), new A()) .fst).snd -→ ((Pair)new Pair(new A(),new B())).snd -→ new Pair(new A(), new B()).snd -→ new B() 19.3 Nominal and Structural Type Systems Before proceeding with the formal definition of FJ, we should pause to exam- ine one fundamental stylistic difference between FJ (and Java) and the typed lambda-calculi that are the main focus in this book. This difference concerns the status of type names. 2. Readers familiar with Abadi and Cardelli’s object calculus (1996) will see a strong similarity to their ς-reduction rule. 252 19 Case Study: Featherweight Java In previous chapters, we have often defined short names for long or com- plex compound types to improve the readability of examples, e.g.: NatPair = {fst:Nat, snd:Nat}; Such definitions are purely cosmetic: the name NatPair is a simple abbre- viation for {fst:Nat,snd:Nat}, and the two are interchangeable in every context. Our formal presentations of the calculi have ignored abbreviations. By contrast, in Java, as in many widely used programming languages, type definitions play a much more significant role. Every compound type used in a Java program has a name, and, when we declare the type of a local variable, a field, or a method parameter, we always do so by giving the name. “Bare” types like {fst:Nat,snd:Nat} simply cannot appear in these positions. These type names play a crucial role in Java’s subtype relation. Whenever a new name is introduced (in a class or interface definition), the programmer explicitly declares which classes and interfaces the new one extends (or, in the case of a new class and an existing interface, “implements”). The compiler checks these declarations to make sure that the facilities provided by the new class or interface really extend those of each super-class or super-interface— this check corresponds to record subtyping in a typed lambda-calculus. The subtype relation is now defined between type names as the reflexive and tran- sitive closure of the declared immediate-subtype relation. If one name has not been declared to be a subtype of another, then it is not. Type systems like Java’s, in which names are significant and subtyping is explicitly declared, are called nominal. Type systems like most of the ones in this book, in which names are inessential and subtyping is defined directly on the structures of types are called structural. Nominal type systems have both advantages and disadvantages over struc- tural presentations. Probably the most important advantage is that the type names in nominal systems are useful not only during typechecking, but at run time as well. Most nominal languages tag each run-time object with a header word containing its type name, represented concretely as a pointer to a run-time data structure describing the type and giving pointers to its immediate supertypes. These type tags are handy for a variety of purposes, including run-time type testing (e.g., Java’s instanceOf test and downcasting operation), printing, marshaling data structures into binary forms for storage in files or transmission over networks, and reflective facilities that permit a program to dynamically investigate the fields and methods of an object that it has been given. Run-time type tags can also be supported in structural sys- tems (see Glew, 1999; League, Shao, and Trifonov, 1999; League, Trifonov, and Shao, 2001; and the citations given there), but they constitute an additional, 19.3 Nominal and Structural Type Systems 253 separate mechanism; in nominal systems, the run-time tags are identified with the compile-time types. A less essential, but pleasant, property of nominal systems is that they of- fer a natural and intuitive account of recursive types—types whose definition mentions the type itself. (We will discuss recursive types in detail in Chap- ter 20.) Such types are ubiquitous in serious programming, being required to describe such common structures as lists and trees, and nominal type sys- tems support them in the most straightforward possible way: referring to List in the body of its own declaration is just as easy as referring to any other type. Indeed, even mutually recursive types are straightforward. We view the set of type names as being given from the beginning, so that, if the definition of type A involves the name B and the definition of B refers to A, there is no issue about “which is defined first.” Of course, recursive types can also be handled in structural type systems. Indeed, high-level languages with structural typing, such as ML, generally “bundle” recursive types with other features, so that, for the programmer, they are just as natural and easy to use as in nominal languages. But in calculi intended for more foundational purposes, such as type safety proofs, the mechanisms required to deal rig- orously with recursive types can become rather heavy, especially if mutually recursive types are allowed. The fact that recursive types come essentially for free in nominal systems is a decided benefit. Another advantage of nominal systems is that checking whether one type is a subtype of another becomes almost trivial. Of course, the compiler must still do the work of verifying that the declared subtype relations are safe, which essentially duplicates the structural subtype relation, but this work needs to be done only once per type, at the point where it is defined, rather than during every subtype check. This makes it somewhat easier to achieve good performance in typecheckers for nominal type systems. In more seri- ous compilers, though, it is not clear that the difference between nominal and structural styles has much effect on performance, since well-engineered typecheckers for structural systems incorporate representation techniques that reduce most subtype checks to a single comparison—see page 222. A final advantage often cited for explicit subtype declarations is that they prevent “spurious subsumption,” where the typechecker fails to reject a pro- gram that uses a value of one type where a completely different, but struc- turally compatible, type is expected. This point is more contentious than the ones above, since there are other—arguably better—ways of preventing spuri- ous subsumption, for example using single-constructor datatypes (page 138) or abstract data types (Chapter 24). Given all these advantages—especially the general usefulness of type tags and the simple treatment of recursive types—it is no surprise to find that 254 19 Case Study: Featherweight Java nominal type systems are the norm in mainstream programming languages. The research literature on programming languages, on the other hand, is al- most completely concerned with structural type systems. One immediate reason for this is that, at least in the absence of recursive types, structural systems are somewhat tidier and more elegant. In a struc- tural setting, a type expression is a closed entity: it carries with it all the information that is needed to understand its meaning. In a nominal system, we are always working with respect to some global collection of type names and associated definitions. This tends to make both definitions and proofs more verbose. A more interesting reason is that the research literature tends to focus on more advanced features—in particular, on powerful mechanisms for type ab- straction (parametric polymorphism, abstract data types, user-defined type operators, functors, etc.)—and on languages such as ML and Haskell that em- body these features. Unfortunately, such features do not fit very comfortably into nominal systems. A type like List(T), for example, seems irreducibly compound—there will be just one definition somewhere in the program for the constructor List, and we need to refer to this definition to see how List(T) behaves, so we cannot treat List(T) as an atomic name. A few nominal languages have been extended with such “generic” features (Myers, Bank, and Liskov, 1997; Agesen, Freund, and Mitchell, 1997; Bracha, Odersky, Stoutamire, and Wadler, 1998; Cartwright and Steele, 1998; Stroustrup, 1997), but the results of such extensions are no longer pure nominal systems, but somewhat complex hybrids of the two approaches. Designers of languages with advanced typing features thus tend to favor the structural approach. A full account of the relation between nominal and structural type systems remains a topic of ongoing research. 19.4 Definitions We now turn to the formal definition of FJ. Syntax The syntax of FJ is given in Figure 19-1. The metavariables A, B, C, D, and E range over class names; f and g range over field names; m ranges over method names; x ranges over parameter names; s and t range over terms; u and v range over values; CL ranges over class declarations; K ranges over construc- tor declarations; M ranges over method declarations. We assume that the set of variables includes the special variable this, but that this is never used as 19.4 Definitions 255 Syntax CL ::= class declarations: class C extends C {C f; K M} K ::= constructor declarations: C(C f) {super(f); this.f=f;} M ::= method declarations: C m(C x) {return t;} t ::= terms: x variable t.f field access t.m(t) method invocation new C(t) object creation (C) t cast v ::= values: new C(v) object creation Subtyping C<:D C <: C C <: D D <: E C <: E CT(C) = class C extends D {...} C <: D Figure 19-1: Featherweight Java (syntax and subtyping) the name of an argument to a method. Instead, it is considered to be implicitly bound in every method declaration. The evaluation rule for method invoca- tion (rule E-InvkNew in Figure 19-3) will substitute an appropriate object for this in addition to substituting argument values for parameters. We write f as shorthand for f1,. . .,fn (similarly C, x, t, etc.) and write M for M1. . . Mn (with no commas). We abbreviate operations on pairs of se- quences similarly, writing “C f” for “C1 f1,. . .,Cn fn”, where n is the length of C and f, “C f;” for the declarations “C1 f1;. . . Cn fn;” and “this.f=f;” for “this.f1=f1;. . . ;this.fn=fn;”. Sequences of field declarations, parameter names, and method declarations are assumed to contain no duplicate names. The declaration class C extends D {C f; K M} introduces a class named C with superclass D. The new class has fields f with types C, a single construc- tor K, and a suite of methods M. The instance variables declared by C are added to the ones declared by D and its superclasses, and should have names distinct from these.3 The methods of C, on the other hand, may either over- 3. In Java, instance variables of superclasses may be redeclared—the redeclaration shadows 256 19 Case Study: Featherweight Java ride methods with the same names that are already present in D or add new functionality special to C. The constructor declaration C(D g, C f) {super(g); this.f=f;} shows how to initialize the fields of an instance of C. Its form is completely deter- mined by the instance variable declarations of C and its superclasses: it must take exactly as many parameters as there are instance variables, and its body must consist of a call to the superclass constructor to initialize its fields from the parameters g, followed by an assignment of the parameters f to the new fields of the same names declared by C. (These constraints are enforced by the typing rule for classes in Figure 19-4.) In full Java, a subclass constructor must contain a call to its superclass constructor (when the superclass con- structor takes arguments); this is the reason that the constructor body here calls super to initialize the superclass’s instance variables. If we did not care about making FJ a literal subset of Java, we could drop the call to super and make each constructor initialize all the instance variables directly. The method declaration D m(C x) {return t;} introduces a method named m with result type D and parameters x of types C. The body of the method is the single statement return t. The variables x are bound in t. The special variable this is also considered bound in t. A class table CT is a mapping from class names C to class declarations CL. A program is a pair (CT,t) of a class table and a term. To lighten the notation in what follows, we always assume a fixed class table CT. Every class has a superclass, declared with extends. This raises a question: what is the superclass of the Object class? There are various ways to deal with this issue; the simplest one (which we adopt here) is to take Object as a distinguished class name whose definition does not appear in the class table. The auxiliary function that looks up fields in the class table is equipped with a special case for Object that returns the empty sequence of fields, denoted •; Object is also assumed to have no methods.4 By looking at the class table, we can read off the subtype relation between classes. We write C <: D when C is a subtype of D—i.e., subtyping is the re- flexive and transitive closure of the immediate subclass relation given by the extends clauses in CT . It is defined formally in Figure 19-1. The given class table is assumed to satisfy some sanity conditions: (1) CT(C) = class C... for every C ∈ dom(CT); (2) Object ∉ dom(CT); (3) for every class name C (except Object) appearing anywhere in CT, we have C ∈ dom(CT); and (4) there are no cycles in the subtype relation induced by CT—that is, the <: relation is antisymmetric. the original in the current class and its subclasses. We omit this feature in FJ. 4. In full Java, the class Object actually has several methods. We ignore these in FJ. 19.4 Definitions 257 Field lookup fields(C) = C f fields(Object) = • CT(C) = class C extends D {C f; K M} fields(D) = D g fields(C) = D g, C f Method type lookup mtype(m,C) = C→C CT(C) = class C extends D {C f; K M} B m (B x) {return t;} ∈ M mtype(m,C) = B→B CT(C) = class C extends D {C f; K M} m is not defined in M mtype(m,C) =mtype(m,D) Method body lookup mbody(m,C) = (x,t) CT(C) = class C extends D {C f; K M} B m (B x) {return t;} ∈ M mbody(m,C) = (x,t) CT(C) = class C extends D {C f; K M} m is not defined in M mbody(m,C) =mbody(m,D) Valid method overriding override(m, D, C→C0) mtype(m,D) = D→D0 implies C = D and C0 = D0 override(m, D, C→C0) Figure 19-2: Featherweight Java (auxiliary definitions) Note that the types defined by the class table are allowed to be recursive, in the sense that the definition of a class A may use the name A in the types of its methods and instance variables. Mutual recursion between class definitions is also allowed. 19.4.1 Exercise [«]: By analogy with the S-Top rule in our lambda-calculus with sub- typing, one might expect to see a rule stating that Object is a supertype of every class. Why don’t we need it here? � Auxiliary Definitions For the typing and evaluation rules, we will need a few auxiliary definitions; these are given in Figure 19-2. The fields of a class C, written fields(C), is a sequence C f pairing the class of each field with its name, for all the fields declared in class C and all of its superclasses. The type of the method m in class C, written mtype(m,C), is a pair, written B→B, of a sequence of argument types B and a single result type B. Similarly, the body of the method m in class C, written mbody(m,C), is a pair, written (x,t), of a sequence of parameters x and a term t. The predicate override(m, D, C→C0) judges whether a method m with argument types C and a result type C0 may be defined in a subclass of 258 19 Case Study: Featherweight Java Evaluation t -→ t′ fields(C) = C f (new C(v)).fi -→ vi (E-ProjNew) mbody(m,C) = (x,t0) (new C(v)).m(u) -→ [x, u, this, new C(v)]t0 (E-InvkNew) C <: D (D)(new C(v)) -→ new C(v) (E-CastNew) t0 -→ t ′ 0 t0.f -→ t ′ 0 .f (E-Field) t0 -→ t ′ 0 t0.m(t) -→ t ′ 0 .m(t) (E-Invk-Recv) ti -→ t ′ i v0.m(v, ti, t) -→ v0.m(v, t ′ i, t) (E-Invk-Arg) ti -→ t ′ i new C(v, ti, t) -→ new C(v, t′i, t) (E-New-Arg) t0 -→ t ′ 0 (C)t0 -→ (C)t ′ 0 (E-Cast) Figure 19-3: Featherweight Java (evaluation) D. In case of overriding, if a method with the same name is declared in the superclass then it must have the same type. Evaluation We use a standard call-by-value operational semantics (Figure 19-3). The three computation rules—for field access, method invocation, and casting—were explained in §19.2. The rest of the rules formalize the call-by-value strategy. The values that can result from normal termination of the evaluator are fully evaluated object creation terms of the form new C(v). Note that the run-time behavior of the cast operation is to test whether the actual type of the object being cast is a subtype of the type declared in the cast. If it is, then the cast operation is thrown away and the result is the object itself. This corresponds exactly to the semantics of Java: a run-time cast does not change an object in any way—it simply either succeeds or else fails and raises an exception. In FJ, instead of raising an exception a failing cast will just get stuck, since there will be no evaluation rule that applies. Typing The typing rules for terms, method declarations, and class declarations are given in Figure 19-4. An environment Γ is a finite mapping from variables to types, written x:C. Typing statements for terms have the form Γ ` t : C, 19.4 Definitions 259 Term typing Γ ` t : C x:C ∈ Γ Γ ` x : C (T-Var) Γ ` t0 : C0 fields(C0) = C f Γ ` t0.fi : Ci (T-Field) Γ ` t0 : C0 mtype(m,C0) = D→C Γ ` t : C C <: D Γ ` t0.m(t) : C (T-Invk) fields(C) = D f Γ ` t : C C <: D Γ ` new C(t) : C (T-New) Γ ` t0 : D D <: C Γ ` (C)t0 : C (T-UCast) Γ ` t0 : D C <: D C ≠ D Γ ` (C)t0 : C (T-DCast) Γ ` t0 : D C 6<: D D 6<: C stupid warning Γ ` (C)t0 : C (T-SCast) Method typing M OK in C x : C, this : C ` t0 : E0 E0 <: C0 CT(C) = class C extends D {...} override(m, D, C→C0) C0 m (C x) {return t0;} OK in C Class typing C OK K = C(D g, C f) {super(g); this.f = f;} fields(D) = D g M OK in C class C extends D {C f; K M} OK Figure 19-4: Featherweight Java (typing) read “in the environment Γ , term t has type C.” The typing rules are syntax directed,5 with one rule for each form of term, save that there are three rules for casts (discussed below). The typing rules for constructors and method invocations check that each argument has a type that is a subtype of the one declared for the corresponding formal parameter. We abbreviate typing statements on sequences in the obvious way, writing Γ ` t : C as shorthand for Γ ` t1 : C1, . . . , Γ ` tn : Cn and C <: D as shorthand for C1 <: D1, . . . , Cn <: Dn. One minor technical innovation in FJ is the introduction of “stupid” casts. There are three rules for type casts: in an upcast the subject is a subclass of the target, in a downcast the target is a subclass of the subject, and in a stupid cast the target is unrelated to the subject. The Java compiler rejects as ill typed a term containing a stupid cast, but we must allow stupid casts in FJ if we are to formulate type safety as a type preservation theorem for a small-step semantics. This is because a sensible term may be reduced to 5. We follow full Java in choosing an algorithmic formulation of the typing relation. Interest- ingly, in full Java this choice is actually forced. See Exercise 19.4.6. 260 19 Case Study: Featherweight Java one containing a stupid cast. For example, consider the following, which uses classes A and B as defined in §19.2: (A)(Object)new B() -→ (A)new B() We indicate the special nature of stupid casts by including the hypothesis stupid warning in the type rule for stupid casts (T-SCast); an FJ typing corre- sponds to a legal Java typing only if it does not contain this rule. Typing statements for method declarations have the form M OK in C, read “method declaration M is well formed if it occurs in class C.” It uses the term typing relation on the body of the method, where the free variables are the parameters of the method with their declared types, plus the special variable this with type C. Typing statements for class declarations have the form CL OK, read “class declaration CL is well formed.” It checks that the constructor applies super to the fields of the superclass and initializes the fields declared in this class, and that each method declaration in the class is ok. The type of a term may depend on the type of any methods it invokes, and the type of a method depends on the type of a term (its body), so it behooves us to check that there is no ill-defined circularity here. Indeed there is none: the circle is broken because the type of each method is explicitly declared. It is possible to load the class table and use it for typechecking before all the classes in it have been checked, so long as each class is eventually checked. 19.4.2 Exercise [««]: A number of design decisions in FJ are dictated by the desire to make it a subset of Java, in the sense that every well- or ill-typed FJ program is well- or ill-typed as a Java program, and the well-typed programs behave the same. Suppose this requirement were dropped—i.e., suppose all we wanted was a Java-like core calculus. How would you change the design of FJ to make it simpler or more elegant? � 19.4.3 Exercise [Recommended, ««« 3]: The operation of assigning a new value to the field of an object is omitted from FJ to simplify its presentation, but it can be added without changing the basic character of the calculus very much. Do this, using the treatment of references in Chapter 13 as a model. � 19.4.4 Exercise [««« 3]: Extend FJ with analogs of Java’s raise and try forms, using the treatment of exceptions in Chapter 14 as a model. � 19.4.5 Exercise [«« 3]: FJ, like full Java, presents the typing relation in algorithmic form. There is no subsumption rule; instead, several of the other rules include subtyping checks among their premises. Can the system be reformulated in a more declarative style, dropping most or all of these premises in favor of a single subsumption rule? � 19.5 Properties 261 19.4.6 Exercise [«««]: Full Java provides both classes and interfaces, which specify the types of methods, but not their implementations. Interfaces are useful because they permit a richer, non-tree-structured, subtype relation: each class has a single superclass (from which it inherits instance variables and method bodies), but may additionally implement any number of interfaces. The presence of interfaces in Java actually forces the choice of an algo- rithmic presentation of the typing relation, which gives each typable term a unique (minimal) type. The reason is an interaction between conditional expressions (written t1 ? t2 : t3 in Java) and interfaces. 1. Show how to extend FJ with interfaces in the style of Java. 2. Show that, in the presence of interfaces, the subtype relation is not nec- essarily closed under joins. (Recall from §16.3 that the existence of joins played a critical role in the minimal typing property for conditionals.) 3. What is Java’s typing rule for conditional expressions? Is it reasonable? � 19.4.7 Exercise [«««]: FJ includes Java’s this keyword, but omits super. Show how to add it. � 19.5 Properties We can prove a standard type-preservation theorem for FJ. 19.5.1 Theorem [Preservation]: If Γ ` t : C and t -→ t′, then Γ ` t′ : C′ for some C′ <: C. � Proof: Exercise [«««]. � We can also show a variant of the standard progress theorem: if a program is well typed, then the only way it can get stuck is if it reaches a point where it cannot perform a downcast. We use the mechanism of evaluation contexts to identify the failing downcast in the latter case. 19.5.2 Lemma: Suppose t is a well-typed term. 1. If t = new C0(t).f, then fields(C0) = C f and f ∈ f. 2. If t = new C0(t).m(s), then mbody(m,C0) = (x,t0) and |x| = |s|. � Proof: Straightforward. � 262 19 Case Study: Featherweight Java 19.5.3 Definition: The set of evaluation contexts for FJ is defined as follows: E ::= evaluation contexts: [ ] hole E.f field access E.m(t) method invocation (receiver) v.m(v,E,t) method invocation (arg) new C(v,E,t) object creation (arg) (C)E cast Each evaluation context is a term with a hole (written [ ]) somewhere inside it. We write E[t] for the ordinary term obtained by replacing the hole in E with t. � Evaluation contexts capture the notion of the “next subterm to be reduced,” in the sense that, if t -→ t′, then we can express t and t′ as t = E[r] and t′ = E[r′] for a unique E, r, and r′, with r -→ r′ by one of the computation rules E-ProjNew, E-InvkNew, or E-CastNew. 19.5.4 Theorem [Progress]: Suppose t is a closed, well-typed normal form. Then either (1) t is a value, or (2) for some evaluation context E, we can express t as t = E[(C)(new D(v))], with D 6<: C. � Proof: Straightforward induction on typing derivations. � The progress property can be sharpened a little: if t contains only upcasts, then it cannot get stuck (and, if the original program contains only upcasts, then evaluation will never produce any casts that are not upcasts). But, in general, we want to use casting to lower the static types of objects, and so we must live with the possibility that casts can fail at run time. In full Java, of course, a cast failure does not stop the whole program: it generates an exception that can be caught by a surrounding exception handler. 19.5.5 Exercise [««« 3]: Starting from one of the lambda-calculus typecheckers, build a typechecker and interpreter for Featherweight Java. � 19.5.6 Exercise [«««« 3]: The original FJ paper (Igarashi, Pierce, and Wadler, 1999) also formalizes polymorphic types in the style of GJ. Extend the typechecker and interpreter from Exercise 19.5.5 to include these features. (You will need to read Chapters 23, 25, 26, and 28 before attempting this exercise.) � 19.6 Encodings vs. Primitive Objects We have seen two contrasting approaches to the semantics and typing of simple object-oriented languages. In Chapter 18, we used combinations of 19.7 Notes 263 features from the simply typed lambda-calculus with records, references, and subtyping to encode objects, classes, and inheritance. In the present chapter, we gave a direct account of a simple language in which objects and classes are primitive mechanisms. Each of these approaches has its uses. Studying object encodings lays bare the fundamental mechanisms of encapsulation and reuse and allows us to compare them to other mechanisms with related aims. These encodings also help in understanding the way objects are translated into yet lower-level lan- guages by compilers, and in understanding the interactions between objects and other language features. Treating objects as primitive, on the other hand, allows us to talk about their operational semantics and typing behavior di- rectly; this kind of presentation is a better tool for high-level language design and documentation. Ultimately, of course, we would like to have both views—a high-level lan- guage including primitive features for objects, classes, etc., with its own typ- ing rules and operational semantics, plus a translation from this language to some lower-level language with just records and functions (or, indeed, an even lower-level language with nothing but registers, pointers, and instruc- tion sequences), and finally a proof that this translation is a correct imple- mentation of the high-level language, in the sense that the translation pre- serves the evaluation and typing properties of the high-level language. Many variants of this exercise have been carried out—for FJ itself by League, Tri- fonov, and Shao (2001), and for other object-oriented core calculi by Hofmann and Pierce (1995b), Bruce (1994, 2002), Abadi, Cardelli, and Viswanathan (1996), and others. 19.7 Notes This chapter is adapted from the original FJ article by Igarashi, Pierce, and Wadler (1999). The main difference in presentation is that we have used a call-by-value operational semantics, for consistency with the rest of the book, while the original used a nondeterministic beta-reduction relation. There have been several proofs of type safety for subsets of Java. In the earliest, Drossopoulou, Eisenbach, and Khurshid (1999), using a technique later mechanically checked by Syme (1997), prove safety for a substantial subset of sequential Java. Like FJ, they use a small-step operational semantics, but they avoid the subtleties of “stupid casts” by omitting casting entirely. Nipkow and Oheimb (1998) give a mechanically checked proof of safety for a somewhat larger core language. Their language does include casts, but it is formulated using a “big-step” operational semantics, which sidesteps the 264 19 Case Study: Featherweight Java stupid cast problem. Flatt, Krishnamurthi, and Felleisen (1998a, 1998b) use a small-step semantics and formalize a language with both assignment and casting, treating stupid casts as in FJ. Their system is somewhat larger than FJ (the syntax, typing, and operational semantics rules take perhaps three times the space), and its safety proof, though correspondingly longer, is of similar complexity. Of these three studies, Flatt, Krishnamurthi, and Felleisen’s is closest to FJ in an important sense: the goal there, as here, is to choose a core calculus that is as small as possible, capturing just the features of Java that are relevant to some particular task. In their case, the task is analyzing an extension of Java with Common Lisp style mixins. The goal of the other two systems mentioned above, on the other hand, is to include as large a subset of Java as possible, since their primary interest is proving the safety of Java itself. The literature on foundations of object-oriented languages contains many papers on formalizing class-based object-oriented languages, either taking classes as primitive (e.g., Wand, 1989a, Bruce, 1994, Bono, Patel, Shmatikov, and Mitchell, 1999b, Bono, Patel, and Shmatikov, 1999a) or translating classes into lower-level mechanisms (e.g., Fisher and Mitchell, 1998, Bono and Fisher, 1998, Abadi and Cardelli, 1996, Pierce and Turner, 1994). A related thread of work considers models of object-oriented languages in which classes are replaced by some form of method override or delegation (Ungar and Smith, 1987), where individual objects may inherit behaviors from other objects. The resulting calculi tend to be somewhat simpler than those for class-based languages, since they deal with a smaller set of concepts. The most highly developed and best known of these is Abadi and Cardelli’s object calculus (1996). Another popular one was developed by Fisher, Honsell, and Mitchell (1994). A rather different approach to objects, classes, and inheritance, known as multi-methods, has been formalized by Castagna, Ghelli, and Longo (1995). The footnote on page 226 gives additional citations. Inside every large language is a small language struggling to get out. . . . —Igarashi, Pierce, and Wadler (1999) Inside every large program is a small program struggling to get out. . . . —Tony Hoare, Efficient Production of Large Programs (1970) I’m fat, but I’m thin inside. Has it ever struck you that there’s a thin man inside every fat man? —George Orwell, Coming Up For Air (1939) P a r t I V Recursive Types 20 Recursive Types We saw in §11.12 how to extend a simple type system to include a type con- structor List(T) whose elements are lists with elements of type T. Lists are just one example of a large class of common structures—also includ- ing queues, binary trees, labeled trees, abstract syntax trees, etc.—that may grow to arbitrary size, but that have a simple, regular structure. An element of List(Nat), for example, is always either nil or else a pair (a “cons cell”) of a number and another List(Nat). Clearly, it does not make sense to pro- vide every one of these structures as a separate, primitive language feature. Instead, we need a general mechanism with which they can be defined from simpler elements, as needed. This mechanism is called recursive types. Consider again the type of lists of numbers.1 We can represent the fact that a list is either nil or a pair using the variant and tuple types defined in §11.10 and §11.7: NatList = ;

The data value carried by nil is trivial, since the nil tag itself already tells

us everything that we need to know about an empty list. The value carried by

the cons tag, on the other hand, is a pair consisting of a number and another

list. The first component of this pair has type Nat,

NatList = ;

while the second component is a list of numbers—i.e., an element of the very

type NatList that we are defining:

NatList = ;

The system studied in this chapter is the simply typed calculus with recursive types. The

examples use a variety of features from earlier chapters; the associated checker for these is

fullequirec. For §20.2, the associated checker is fullisorec.

1. We ignore, in the rest of this chapter, the question of how to give a single, generic definition

of lists with elements of an arbitrary type T. To deal with this, we also need the mechanism of

type operators, which will be introduced in Chapter 29.

268 20 Recursive Types

This equation is not just a simple definition—that is, we are not giving a new

name to a phrase whose meaning we already understand—since the right-

hand side mentions the very name that we are in the process of defining.

Instead, we can think of it as a specification of an infinite tree:

{nil: , cons: }

Unit { , }

Nat {nil: , cons: }

Unit { , }

Nat {nil: , cons: }

Unit ..
.

The recursive equation specifying this infinite tree type is similar to the equa-

tion specifying the recursive factorial function on page 52. Here, as there,

it is convenient to make this equation into a proper definition by moving the

“loop” over to the right-hand side of the =.2 We do this by introducing an

explicit recursion operator µ for types:

NatList = µX. ;

Intuitively, this definition is read, “Let NatList be the infinite type satisfying

the equation X = .”

We will see in §20.2 that there are actually two somewhat different ways

of formalizing recursive types—the so-called equi-recursive and iso-recursive

presentations—differing in the amount of help that the programmer is ex-

pected to give to the typechecker in the form of type annotations. In the pro-

gramming examples in the following section, we use the lighter equi-recursive

presentation.

20.1 Examples

Lists

First, let’s finish off the example of lists of numbers that we started above.

To program with lists, we need a constant nil, a constructor cons for adding

2. The reason this move is convenient is that it allows us to talk about recursive types without

giving them names. However, there are also some advantages to working with explicitly named

recursive types—see the discussion of nominal vs. structural type systems in §19.3.

20.1 Examples 269

an element to the front of an existing list, an isnil operation that takes a

list and returns a boolean, and destructors hd and tl for extracting the head

and tail of a non-empty list. We defined all these as built-in operations in

Figure 11-13; our job here is to build them from simpler parts.

The definitions of nil and cons follow directly from the definition of

NatList as a two-field variant type.

nil = as NatList;

ñ nil : NatList

cons = λn:Nat. λl:NatList. as NatList;

ñ cons : Nat → NatList → NatList

(Recall from §11.10 that expressions of the form as T are used to in-

troduce values of variant types: the value t is tagged with the label l and “in-

jected” into the variant type T. Also, note that the typechecker here automat-

ically “unfolds” the recursive type NatList to the variant type .)

The rest of the basic operations on lists involve testing their structure and

extracting appropriate parts. They are all implemented in terms of case.

isnil = λl:NatList. case l of

⇒ true

| ⇒ false;

ñ isnil : NatList → Bool

hd = λl:NatList. case l of ⇒ 0 | ⇒ p.1;

ñ hd : NatList → Nat

tl = λl:NatList. case l of ⇒ l | ⇒ p.2;

ñ tl : NatList → NatList

We’ve arbitrarily decided to define hd of an empty list to be 0 and tl of the

empty list to be the empty list. We might alternatively have raised exceptions

in these cases.

We can use all these definitions together to write a recursive function that

sums the elements of a list:

sumlist = fix (λs:NatList→Nat. λl:NatList.

if isnil l then 0 else plus (hd l) (s (tl l)));

ñ sumlist : NatList → Nat

270 20 Recursive Types

mylist = cons 2 (cons 3 (cons 5 nil));

sumlist mylist;

ñ 10 : Nat

Note that, although NatList itself is an infinitely long type expression,

all its elements are finite lists (because there is no way to use the pairing and

tagging primitives or the call-by-value fix to build infinitely large structures).

20.1.1 Exercise [««]: One presentation of labeled binary trees defines a tree to be

either a leaf (with no label) or else an interior node with a numeric label

and two child trees. Define a type NatTree and suitable operations for con-

structing, destructing, and testing trees. Write a function that performs a

depth-first traversal of a tree and returns a list of the labels it finds. Use the

fullequirec checker to test your code. �

Hungry Functions

Another example illustrating a somewhat trickier use of recursive types is a

type of “hungry functions” that can accept any number of numeric arguments

and always return a new function that is hungry for more:

Hungry = µA. Nat→A;

An element of this type can be defined using the fix operator:

f = fix (λf: Nat→Hungry. λn:Nat. f);

ñ f : Hungry

f 0 1 2 3 4 5;

ñ : Hungry

Streams

A more useful variant of the Hungry type above is the type Stream of func-

tions that can consume an arbitrary number of unit values, each time return-

ing a pair of a number and a new stream.

Stream = µA. Unit→{Nat,A};

We can define two “destructors” for streams; if s is a stream, then hd s is the

first number it returns when we pass it unit.

20.1 Examples 271

hd = λs:Stream. (s unit).1;

ñ hd : Stream → Nat

Similarly, tl s is the new stream that we obtain when we pass unit to s.

tl = λs:Stream. (s unit).2;

ñ tl : Stream → Stream

To construct a stream, we use fix as above:

upfrom0 = fix (λf: Nat→Stream. λn:Nat. λ_:Unit. {n,f (succ n)}) 0;

ñ upfrom0 : Stream

hd upfrom0;

ñ 0 : Nat

hd (tl (tl (tl upfrom0)));

ñ 3 : Nat

20.1.2 Exercise [Recommended, ««]: Define a stream that yields successive ele-

ments of the Fibonacci sequence (1, 1, 2, 3, 5, 8, 13, . . .). �

Streams can be further generalized to a simple form of processes—functions

that accept a number and return a number and a new process.

Process = µA. Nat→{Nat,A};

For example, here is a process that, at each step, returns the sum of all the

numbers it has been given so far:

p = fix (λf: Nat→Process. λacc:Nat. λn:Nat.

let newacc = plus acc n in

{newacc, f newacc}) 0;

ñ p : Process

As we did for streams, we can define auxiliary functions for interacting with

processes:

curr = λs:Process. (s 0).1;

ñ curr : Process → Nat

send = λn:Nat. λs:Process. (s n).2;

ñ send : Nat → Process → Process

If we send the process p the numbers 5, 3, and 20, the number it returns in

response to the last interaction is 28.

curr (send 20 (send 3 (send 5 p)));

ñ 28 : Nat

272 20 Recursive Types

Objects

A slight rearrangement of the last example gives us another familiar idiom of

interacting with data: objects. For instance, here is the type of counter objects

that keep track of a number and allow us to either query or increment it:

Counter = µC. {get:Nat, inc:Unit→C};

Note that our treatment of objects here is purely functional (like the one in

Chapter 19 and unlike Chapter 18): sending a counter object the inc message

does not cause this object to mutate its state internally; instead, the opera-

tion returns a new counter object with incremented internal state. The use of

recursive types here allows us to specify that the returned object has exactly

the same type as the original.

The only difference between these objects and the processes discussed

above is that an object is a recursively defined record (containing a function),

whereas a process was a recursively defined function (returning a tuple). The

reason this change in point of view is useful is that we can extend our record

to include more than one function—for example, a decrement operation:

Counter = µC. {get:Nat, inc:Unit→C, dec:Unit→C};

To create a counter object, we use the fixed-point combinator, as we did

above.

c = let create = fix (λf: {x:Nat}→Counter. λs: {x:Nat}.

{get = s.x,

inc = λ_:Unit. f {x=succ(s.x)},

dec = λ_:Unit. f {x=pred(s.x)} })

in create {x=0};

ñ c : Counter

To invoke one of c’s operations, we simply project out the appropriate field:

c1 = c.inc unit;

c2 = c1.inc unit;

c2.get;

ñ 2 : Nat

20.1.3 Exercise [««]: Extend the Counter type and the counter c above to include

backup and reset operations (as we did in §18.7): invoking backup causes

the counter to store its current value in a separate internal register; calling

reset causes the counter’s value to be reset to the value in this register. �

20.1 Examples 273

Recursive Values from Recursive Types

A more surprising use of recursive types—and one that clearly reveals their

expressive power—is a well-typed implementation of the fixed-point combi-

nator. For any type T, we can define a fixed-point constructor for functions

on T as follows.

fixT = λf:T→T. (λx:(µA.A→T). f (x x)) (λx:(µA.A→T). f (x x));

ñ fixT : (T→T) → T

Note that, if we erase types, this term is precisely the untyped fixed point

combinator that we saw on page 65.

The key trick here is using a recursive type to type the two occurrences of

the subexpression x x. As we observed in Exercise 9.3.2, typing this term re-

quires that x have an arrow type whose domain is the type of x itself. Clearly,

there is no finite type with this property, but the infinite type µA.A→T does

the job perfectly.

A corollary of this example is that the presence of recursive types breaks

the strong normalization property: we can use the fixT combinator to write

a well-typed term whose evaluation (when applied to unit) will diverge.

divergeT = λ_:Unit. fixT (λx:T. x);

ñ divergeT : Unit → T

Moreover, since we can can obtain such terms for every type, it follows that

every type in this system is inhabited, unlike λ→.
3

Untyped Lambda-Calculus, Redux

Perhaps the best illustration of the power of recursive types is the fact that

we can embed the whole untyped lambda-calculus—in a well-typed way—into

a statically typed language with recursive types. Let D be the following type:4

D = µX.X→X;

Define an “injection function” lam mapping functions from D to D into ele-

ments of D as follows:

3. This fact makes systems with recursive types useless as logics: if we interpret types as

logical propositions following the Curry-Howard correspondence (see §9.4) and read “type T is

inhabited” as “proposition T is provable,” then the fact that every type is inhabited means that

every proposition in the logic is provable—that is, the logic is inconsistent.

4. Readers familiar with denotational semantics will observe that D’s definition is precisely

the defining property of the universal domains used in semantic models of the pure lambda-

calculus.

274 20 Recursive Types

lam = λf:D→D. f as D;

ñ lam : D

To apply one element of D to another, we simply unfold the type of the first,

yielding a function, and apply this to the second:

ap = λf:D. λa:D. f a;

ñ ap : D

Now, suppose M is a closed lambda-term involving just variables, abstrac-

tions, and applications. Then we can construct an element of D representing

M, written M?, in a uniform way as follows:

x? = x

(λx.M)? = lam (λx:D. M?)

(M N)? = ap M? N?

For example, here is the untyped fixed point combinator expressed as an

element of D:

fixD = lam (λf:D.

ap (lam (λx:D. ap f (ap x x)))

(lam (λx:D. ap f (ap x x))));

ñ fixD : D

This embedding of the pure lambda-calculus can be extended to include

features such as numbers. We change the definition of D to a variant type

with one tag for numbers and one for functions:

D = µX. ;

That is, an element of D is either a number or a function from D to D, tagged

nat or fn, respectively. The implementation of the lam constructor is essen-

tially the same as before:

lam = λf:D→D. as D;

ñ lam : (D→D) → D

The implementation of ap, though, is different in an interesting way:

ap = λf:D. λa:D.

case f of

⇒ divergeD unit

| ⇒ f a;

20.2 Formalities 275

ñ ap : D → D → D

Before we can apply f to a, we need to extract a function from f with a case.

This forces us to specify how application behaves when f is not a function.

(In this example, we just diverge; we could also raise an exception.) Note

how closely the tag-checking here resembles the run-time tag checking in

an implementation of a dynamically typed language such as Scheme. In this

sense, typed computation may be said to “include” untyped or dynamically

typed computation.

Similar tag checking is needed in order to define the successor function on

elements of D:

suc = λf:D. case f of

⇒ ( as D)

| ⇒ divergeD unit;

ñ suc : D → D

The injection of 0 into D is trivial:

zro = as D;

ñ zro : D

20.1.4 Exercise [«]: Extend this encoding with booleans and conditionals, and en-

code the terms if false then 1 else 0 and if false then 1 else false as

elements of D. What happens when we evaluate these terms? �

20.1.5 Exercise [Recommended, ««]: Extend the datatype D to include records

D = µX. ;

and implement record construction and field projection. For simplicity, use

natural numbers as field labels—i.e., records are represented as functions

from natural numbers to elements of D. Use the fullequirec checker to test

your extension. �

20.2 Formalities

In the literature on type systems, there are two basic approaches to recursive

types. The essential difference between them is captured in their response

to a simple question: What is the relation between the type µX.T and its

one-step unfolding? For example, what is the relation between NatList and

?

276 20 Recursive Types

→ µ Extends λ→ (9-1)

t ::= … terms:

fold [T] t folding

unfold [T] t unfolding

v ::= … values:

fold [T] v folding

T ::= … types:

X type variable

µX.T recursive type

New evaluation rules t -→ t′

unfold [S] (fold [T] v1) -→ v1

(E-UnfldFld)

t1 -→ t
′
1

fold [T] t1 -→ fold [T] t
′
1

(E-Fld)

t1 -→ t
′
1

unfold [T] t1 -→ unfold [T] t
′
1

(E-Unfld)

New typing rules Γ ` t : T

U = µX.T1 Γ ` t1 : [X, U]T1

Γ ` fold [U] t1 : U
(T-Fld)

U = µX.T1 Γ ` t1 : U

Γ ` unfold [U] t1 : [X, U]T1
(T-Unfld)

Figure 20-1: Iso-recursive types (λµ)

1. The equi-recursive approach takes these two type expressions as definition-

ally equal—interchangeable in all contexts—since they stand for the same

infinite tree.5 It is the typechecker’s responsibility to make sure that a

term of one type will be allowed as an argument to a function expecting

the other, etc.

The pleasant thing about the equi-recursive treatment is that allowing type

expressions to be infinite6 is the only alteration to the declarative presen-

tations of the systems we already understand. Existing definitions, safety

theorems, and proofs remain unchanged, as long as they do not depend

on induction on type expressions (which naturally no longer works).

Of course, the implementation of equi-recursive types requires some work,

since typechecking algorithms cannot work directly with infinite struc-

tures. Exactly how this can be achieved is the topic of Chapter 21.

2. The iso-recursive approach, on the other hand, takes a recursive type and

its unfolding as different, but isomorphic.

Formally, the unfolding of a recursive type µX.T is the type obtained by

taking the body T and replacing all occurrences of X by the whole recur-

5. The mapping from µ-types to their infinite tree expansions is defined precisely in §21.8.

6. Strictly speaking, we should say regular—see §21.7.

20.2 Formalities 277

sive type—i.e., using the standard notation for substitution, it is [X ,

(µX.T)]T. For example, the type NatList, i.e.,

µX.,

unfolds to

}>.

In a system with iso-recursive types, we introduce, for each recursive type

µX.T, a pair of functions

unfold[µX.T] : µX.T→ [X, µX.T]T

fold[µX.T] : [X, µX.T]T→ µX.T

that “witness the isomorphism” by mapping values back and forth be-

tween the two types:

µX.T [X, µX.T]T

fold[µX.T]

unfold[µX.T]

The fold and unfold maps are provided as primitives by the language, as

described in Figure 20-1. The fact that they form an isomorphism is cap-

tured by the evaluation rule E-UnfldFld, which annihilates a fold when

it meets a corresponding unfold. (The evaluation rule does not require

the type annotations on the fold and the unfold to be the same, since

we would have to invoke the typechecker at run time to verify such a con-

straint. However, in the evaluation of a well-typed program, these two type

annotations will be equal whenever E-UnfldFld is applied.)

Both approaches are widely used in both theoretical studies and program-

ming language designs. The equi-recursive style is arguably more intuitive,

but places stronger demands on the typechecker, which must effectively infer

the points where fold and unfold annotations should occur. Moreover, the

interactions between equi-recursive types and other advanced typing features

such as bounded quantification and type operators can be quite complex,

leading to significant theoretical difficulties (e.g. Ghelli, 1993; Colazzo and

Ghelli, 1999) or even undecidable typechecking problems (Solomon, 1978).

The iso-recursive style is notationally somewhat heavier, requiring pro-

grams to be decorated with fold and unfold instructions wherever recursive

278 20 Recursive Types

types are used. In practice, however, these annotations can often be “hidden”

by coalescing them with other annotations. In languages in the ML family, for

example, every datatype definition implicitly introduces a recursive type.

Each use of one of the constructors to build a value of the datatype implicitly

includes a fold, and each constructor appearing in a pattern match implicitly

forces an unfold. Similarly, in Java each class definition implicitly introduces

a recursive type, and invoking a method on an object involves an implicit

unfold. This felicitous overlap of mechanisms makes the iso-recursive style

quite palatable in practice.

For example, here is the NatList example in iso-recursive form. First, it is

convenient to define an abbreviation for the unfolded form of NatList:

NLBody = ;

Now, nil is defined by building a variant, of type NLBody, and then folding it

up as a NatList; cons is similar.

nil = fold [NatList] ( as NLBody);

cons = λn:Nat. λl:NatList. fold [NatList] as NLBody;

Conversely, the definitions of the isnil, hd, and tl operations need to take a

NatList and consider it as a variant so that they can perform a case analysis

on its tag. This is achieved by unfolding the argument l:

isnil = λl:NatList.

case unfold [NatList] l of

⇒ true

| ⇒ false;

hd = λl:NatList.

case unfold [NatList] l of

⇒ 0

| ⇒ p.1;

tl = λl:NatList.

case unfold [NatList] l of

⇒ l

| ⇒ p.2;

20.2.1 Exercise [Recommended, ««]: Reformulate some of the other examples in

§20.1 (in particular, the fixT example on page 273) with explicit fold and

unfold annotations. Check them using the fullisorec checker. �

20.2.2 Exercise [«« 3]: Sketch proofs of the progress and preservation theorems

for the iso-recursive system. �

20.3 Subtyping 279

20.3 Subtyping

The final question that we need to address in this chapter concerns the combi-

nation of recursive types with the other major refinement of the simply typed

lambda-calculus that we have seen so far—subtyping. For example, supposing

that the type Even is a subtype of Nat, what should be the relation between

the types µX.Nat→(Even×X) and µX.Even→(Nat×X)?

The simplest way to think through such questions is to view them “in

the limit”—i.e., using an equi-recursive treatment of recursive types. In the

present example, the elements inhabiting both types can be thought of as

simple reactive processes (cf. page 271): given a number, they return another

number plus a new process that is ready to receive a number, and so on. Pro-

cesses belonging to the first type always yield even numbers and are capable

of accepting arbitrary numbers. Those belonging to the second type yield ar-

bitrary numbers, but expect always to be given even numbers. The constraints

both on what arguments the function must accept and on what results it may

return are more demanding for the first type, so intuitively we expect the

first to be a subtype of the second. We can draw a picture summarizing these

calculations as follows:

<:<: <:<: Nat →Nat → × × .. . Nat → Nat → × × .. . Even Even Even Even :> <: <::>

<: Can this intuitive argument be made precise? Indeed it can, as we shall see in Chapter 21. 20.4 Notes Recursive types in computer science go back at least to Morris (1968). Ba- sic syntactic and semantic properties (without subtyping) are collected in Cardone and Coppo (1991). Properties of infinite and regular trees are sur- 280 20 Recursive Types veyed by Courcelle (1983). Basic syntactic and semantic properties of recur- sive types without subtyping were established in early papers by Huet (1976) and MacQueen, Plotkin, and Sethi (1986). The relation between iso- and equi- recursive systems was explored by Abadi and Fiore (1996). Additional cita- tions on recursive types with subtyping can be found in §21.12. Morris (1968, pp. 122–124) first observed that recursive types can be used to construct a well-typed fix operator for terms (§20.1). The two formulations of recursive types have been around since the earliest work in the area, but the pleasantly mnemonic terms iso-recursive and equi- recursive are a recent coinage by Crary, Harper, and Puri (1999). 21 Metatheory of Recursive Types In Chapter 20 we saw two alternative presentations of recursive types: equi- recursive types, which are definitionally equivalent to their unfoldings, and iso-recursive types, where this equivalence is explicitly witnessed by fold and unfold terms. In this chapter, we develop the theoretical foundations of typecheckers for equi-recursive types. (Implementing iso-recursive types is comparatively straightforward.) We will deal with a system including both recursive types and subtyping, since these are often combined in practice. A system with equi-recursive types but not subtyping would be only a little simpler, since we would still need to check equivalence of recursive types. We saw in Chapter 20 that subtyping for equi-recursive types can be un- derstood intuitively in terms of infinite subtyping derivations over infinite types. Our job here is to make these intuitions precise using the mathematical framework of coinduction, and to draw a precise connection between infinite trees and derivations and the finite representations manipulated by an actual subtyping algorithm. We begin in §21.1 by reviewing the basic theory of inductive and coinduc- tive definitions and their associated proof principles. §21.2 and §21.3 instan- tiate this general theory for the case of subtyping, defining both the familiar inductive subtype relation on finite types and its coinductive extension to in- finite types. §21.4 makes a brief detour to consider some issues connected with the rule of transitivity (a notorious troublemaker in subtyping systems, as we have seen). §21.5 derives simple algorithms for checking membership in inductively and co-inductively defined sets; §21.6 considers more refined algorithms. These algorithms are applied to subtyping for the important spe- cial case of “regular” infinite types in §21.7. §21.8 introduces µ-types as a finite notation for representing infinite types and proves that the more com- plex (but finitely implementable) subtype relation on µ-types corresponds to The system studied in this chapter is the simply typed calculus with subtyping (Figure 15-1), products (11-5), and equi-recursive types. The corresponding checker is equirec. 282 21 Metatheory of Recursive Types the ordinary coinductive definition of subtyping between infinite types. §21.9 proves termination of the subtyping algorithm for µ-types. §21.10 compares this algorithm with another algorithm due to Amadio and Cardelli. §21.11 briefly discusses iso-recursive types. 21.1 Induction and Coinduction Assume we have fixed some universal set U as the domain of discourse for our inductive and coinductive definitions.U represents the set of “everything in the world,” and the role of an inductive or coinductive definition will be to pick out some subset of U. (Later on, we are going to choose U to be the set of all pairs of types, so that subsets of U are relations on types. For the present discussion, an arbitrary setU will do.) 21.1.1 Definition: A function F ∈ P(U) → P(U) is monotone if X ⊆ Y implies F(X) ⊆ F(Y). (Recall that P(U) is the set of all subsets of U.) � In the following, we assume that F is some monotone function on P(U). We often refer to F as a generating function. 21.1.2 Definition: Let X be a subset of U. 1. X is F-closed if F(X) ⊆ X. 2. X is F-consistent if X ⊆ F(X). 3. X is a fixed point of F if F(X) = X. � A useful intuition for these definitions is to think of the elements of U as some sort of statements or assertions, and of F as representing a “justifica- tion” relation that, given some set of statements (premises), tells us what new statements (conclusions) follow from them. An F-closed set, then, is one that cannot be made any bigger by adding elements justified by F—it already con- tains all the conclusions that are justified by its members. An F-consistent set, on the other hand, is one that is “self-justifying”: every assertion in it is justified by other assertions that are also in it. A fixed point of F is a set that is both closed and consistent: it includes all the justifications required by its members, all the conclusions that follow from its members, and nothing else. 21.1.3 Example: Consider the following generating function on the three-element universeU = {a,b, c}: E1(∅) = {c} E1({a,b}) = {c} E1({a}) = {c} E1({a, c}) = {b, c} E1({b}) = {c} E1({b, c}) = {a,b, c} E1({c}) = {b, c} E1({a,b, c}) = {a,b, c} 21.1 Induction and Coinduction 283 There is just one E1-closed set—{a,b, c}—and four E1-consistent sets—∅, {c}, {b, c}, {a,b, c}. E1 can be represented compactly by a collection of inference rules: c c b b c a Each rule states that if all of the elements above the bar are in the input set, then the element below is in the output set. � 21.1.4 Theorem [Knaster-Tarski (Tarski, 1955)]: 1. The intersection of all F-closed sets is the least fixed point of F . 2. The union of all F-consistent sets is the greatest fixed point of F . � Proof: We consider only part (2); the proof of part (1) is symmetric. Let C = {X |X ⊆ F(X)} be the collection of all F-consistent sets, and let P be the union of all these sets. Taking into account the fact that F is monotone and that, for any X ∈ C , we know both that X is F-consistent and that X ⊆ P , we obtain X ⊆ F(X) ⊆ F(P). Consequently, P = ⋃ X∈C X ⊆ F(P), i.e. P is F-consistent. Moreover, by its definition, P is the largest F-consistent set. Using the monotonicity of F again, we obtain F(P) ⊆ F(F(P)). This means, by the definition of C , that F(P) ∈ C . Hence, as for any member of C , we have F(P) ⊆ P , i.e. P is F-closed. Now we have established both that P is the largest F-consistent set and that P is a fixed point of F , so P is the largest fixed point. � 21.1.5 Definition: The least fixed point of F is written µF . The greatest fixed point of F is written νF . � 21.1.6 Example: For the sample generating function E1 shown above, we have µE1 = νE1 = {a,b, c}. � 21.1.7 Exercise [«]: Suppose a generating function E2 on the universe {a,b, c} is defined by the following inference rules: a c b a b c Write out the set of pairs in the relation E2 explicitly, as we did for E1 above. List all the E2-closed and E2-consistent sets. What are µE2 and νE2? � 284 21 Metatheory of Recursive Types Note that µF itself is F-closed (hence, it is the smallest F-closed set) and that νF is F-consistent (hence, it is the largest F-consistent set). This obser- vation gives us a pair of fundamental reasoning tools: 21.1.8 Corollary [of 21.1.4]: 1. Principle of induction: If X is F-closed, then µF ⊆ X. 2. Principle of coinduction: If X is F-consistent, then X ⊆ νF . � The intuition behind these principles comes from thinking of the set X as a predicate, represented as its characteristic set—the subset of U for which the predicate is true; showing that property X holds of an element x is the same as showing that x is in the set X. Now, the induction principle says that any property whose characteristic set is closed under F (i.e., the property is preserved by F) is true of all the elements of the inductively defined set µF . The coinduction principle, on the other hand, gives us a method for es- tablishing that an element x is in the coinductively defined set νF . To show x ∈ νF , it suffices to find a set X such that x ∈ X and X is F-consistent. Al- though it is a little less familiar than induction, the principle of coinduction is central to many areas of computer science; for example, it is the main proof technique in theories of concurrency based on bisimulation, and it lies at the heart of many model checking algorithms. The principles of induction and coinduction are used heavily throughout the chapter. We do not write out every inductive argument in terms of gen- erating functions and predicates; instead, in the interest of brevity, we often rely on familiar abbreviations such as structural induction. Coinductive argu- ments are presented more explicitly. 21.1.9 Exercise [Recommended, «««]: Show that the principles of ordinary induc- tion on natural numbers (2.4.1) and lexicographic induction on pairs of num- bers (2.4.4) follow from the principle of induction in 21.1.8. � 21.2 Finite and Infinite Types We are going to instantiate the general definitions of greatest fixed points and the coinductive proof method with the specifics of subtyping. Before we can do this, though, we need to show precisely how to view types as (finite or infinite) trees. For brevity, we deal in this chapter with just three type constructors:→, × , and Top. We represent types as (possibly infinite) trees with nodes labeled by 21.2 Finite and Infinite Types 285 one of the symbols→, × , or Top. The definition is specialized to our present needs; for a general treatment of infinite labeled trees see Courcelle (1983). We write {1,2}∗ for the set of sequences of 1s and 2s. Recall that the empty sequence is written •, and ik stands for k copies of i. If π and σ are sequences, then π,σ denotes the concatenation of π and σ . 21.2.1 Definition: A tree type1 (or, simply, a tree) is a partial function T ∈ {1,2}∗ ⇀ {→, × ,Top} satisfying the following constraints: • T(•) is defined; • if T(π,σ) is defined then T(π) is defined; • if T(π) = → or T(π) = × then T(π,1) and T(π,2) are defined; • if T(π) = Top then T(π,1) and T(π,2) are undefined. A tree type T is finite if dom(T) is finite. The set of all tree types is written T ; the subset of all finite tree types is written Tf . � For notational convenience, we write Top for the tree T with T(•) = Top. When T1 and T2 are trees, we write T1×T2 for the tree with (T1×T2)(•) = × and (T1×T2)(i,π) = Ti(π) and T1→T2 for the tree with (T1→T2)(•) = → and (T1→T2)(i,π) = Ti(π), for i = 1,2. For example, (Top×Top)→Top denotes the finite tree type T defined by the function with T(•) = → and T(1) = × and T(2) = T(1,1) = T(1,2) = Top. We use ellipses informally for describing non-finite tree types. For example, Top→(Top→(Top→...)) corresponds to the type T defined by T(2k) = →, for all k ≥ 0, and T(2k,1) = Top, for all k ≥ 0. Figure 21-1 illustrates these conventions. The set of finite tree types can be defined more compactly by a grammar: T ::= Top T×T T→T Formally, Tf is the least fixed point of the generating function described by the grammar. The universe of this generating function is the set of all finite and infinite trees labeled with Top, →, and × (i.e., the set formed by gener- alizing Definition 21.2.1 by dropping its two last conditions). The whole set T can be derived from the same generating function by taking the greatest fixed point instead of the least. 1. The locution “tree type” is slightly awkward, but it will help to keep things straight when we discuss the alternative presentation of recursive types as finite expressions involving µ (“µ-types”) in §21.8. 286 21 Metatheory of Recursive Types (Top×Top)→Top Top→(Top→(Top→...)) → Top× Top Top Top →Top Top → → . . . 1 1 1 1 2 2 1 2 2 2 Figure 21-1: Sample tree types. 21.2.2 Exercise [Recommended, ««]: Following the ideas in the previous paragraph, suggest a universe U and a generating function F ∈ P(U) → P(U) such that the set of finite tree types Tf is the least fixed point of F and the set of all tree types T is its greatest fixed point. � 21.3 Subtyping We define subtype relations on finite tree types and on tree types in general as least and greatest fixed points, respectively, of monotone functions on certain universes. For subtyping on finite tree types the universe is the set Tf × Tf of pairs of finite tree types; our generating function will map subsets of this universe—that is, relations on Tf—to other subsets, and their fixed points will also be relations on Tf . For subtyping on arbitrary (finite or infinite) trees, the universe is T ×T . 21.3.1 Definition [Finite subtyping]: Two finite tree types S and T are in the sub- type relation (“S is a subtype of T”) if (S,T) ∈ µSf , where the monotone func- tion Sf ∈ P(Tf ×Tf )→ P(Tf ×Tf ) is defined by Sf (R) = {(T,Top) | T ∈ Tf } ∪ {(S1×S2,T1×T2) | (S1,T1), (S2,T2) ∈ R} ∪ {(S1→S2,T1→T2) | (T1,S1), (S2,T2) ∈ R}. This generating function precisely captures the effect of the standard defini- tion of the subtype relation by a collection of inference rules: T <: Top S1 <: T1 S2 <: T2 S1×S2 <: T1×T2 21.3 Subtyping 287 T1 <: S1 S2 <: T2 S1→S2 <: T1→T2 The statement S <: T above the line in the second and third rules should be read as “if the pair (S,T) is in the argument to Sf ” and below the line as “then (S,T) is in the result.” � 21.3.2 Definition [Infinite subtyping]: Two (finite or infinite) tree types S and T are in the subtype relation if (S,T) ∈ νS , where S ∈ P(T × T ) → P(T × T ) is defined by: S(R) = {(T,Top) | T ∈ T } ∪ {(S1×S2,T1×T2) | (S1,T1), (S2,T2) ∈ R} ∪ {(S1→S2,T1→T2) | (T1,S1), (S2,T2) ∈ R}. Note that the inference rule presentation of this relation is precisely the same as for the inductive relation above: all that changes is that we consider a larger universe of types and take a greatest instead of a least fixed point. � 21.3.3 Exercise [«]: Check that νS is not the whole of T × T by exhibiting a pair (S,T) that is not in νS . � 21.3.4 Exercise [«]: Is there a pair of types (S,T) that is related by νS , but not by µS? What about a pair of types (S,T) that is related by νSf , but not by µSf ? � One fundamental property of the subtype relation on infinite tree types— the fact that it is transitive—should be verified right away. (We have already seen in §16.1 that subtyping on finite types is transitive.) If the subtype rela- tion were not transitive, the critical property of preservation of types under evaluation would immediately fail. To see this, suppose that there were types S, T, and U with S<:T and T<:U but not S<:U. Let s be a value of type S and f a function of type U→Top. Then the term (λx:T. f x) s could be typed, using the rule of subsumption once for each application, but this term reduces in one step to the ill-typed term f s. 21.3.5 Definition: A relation R ⊆ U×U is transitive if R is closed under the mono- tone function TR(R) = {(x, y) | ∃z ∈ U. (x, z), (z, y) ∈ R}—i.e., if TR(R) ⊆ R. � 21.3.6 Lemma: Let F ∈ P(U×U) → P(U×U) be a monotone function. If TR(F(R)) ⊆ F(TR(R)) for any R ⊆ U×U, then νF is transitive. � Proof: Since νF is a fixed point, νF = F(νF), implying TR(νF) = TR(F(νF)). Therefore, by the lemma’s assumption, TR(νF) ⊆ F(TR(νF)). In other words, TR(νF) is F-consistent, so, by the principle of coinduction, TR(νF) ⊆ νF . Equivalently, νF is transitive by Definition 21.3.5. � 288 21 Metatheory of Recursive Types This lemma is reminiscent of the traditional technique for establishing redundancy of the transitivity rule in inference systems, often called “cut- elimination proofs” (see §16.1). The condition TR(F(R)) ⊆ F(TR(R)) corre- sponds to the crucial step in this technique: given that a certain statement can be obtained by taking some statements from R, applying rules from F , and then applying the rule of transitivity TR, we argue that the statement can instead be obtained by reversing the steps—first applying the rule of transi- tivity, and then rules from F . We use the lemma to establish transitivity of the subtype relation. 21.3.7 Theorem: νS is transitive. � Proof: By Lemma 21.3.6, it suffices to show that TR(S(R)) ⊆ S(TR(R)) for any R ⊆ T × T . Let (S,T) ∈ TR(S(R)). By the definition of TR, there exists some U ∈ T such that (S,U), (U,T) ∈ S(R). Our goal is to show that (S,T) ∈ S(TR(R)). Consider the possible shapes of U. Case: U = Top Since (U,T) ∈ S(R), the definition of S implies that T must be Top. But (A,Top) ∈ S(Q) for any A and Q; in particular, (S,T) = (S,Top) ∈ S(TR(R)). Case: U = U1×U2 If T = Top, then (S,T) ∈ S(TR(R)) as in the previous case. Otherwise, (U,T) ∈ S(R) implies T = T1×T2, with (U1,T1), (U2,T2) ∈ R. Similarly, (S,U) ∈ S(R) implies S = S1×S2, with (S1,U1), (S2,U2) ∈ R. By the definition of TR, we have (S1,T1), (S2,T2) ∈ TR(R), from which (S1×S2,T1×T2) ∈ S(TR(R)) follows from the definition of S . Case: U = U1→U2 Similar. � 21.3.8 Exercise [Recommended, ««]: Show that the subtype relation on infinite tree types is also reflexive. � The following section continues the discussion of transitivity by compar- ing its treatment in standard accounts of subtyping for finite types and in the present account of subtyping for infinite tree types. It can be skipped or skimmed on a first reading. 21.4 A Digression on Transitivity We saw in Chapter 16 that standard formulations of inductively defined sub- type relations generally come in two forms: a declarative presentation that is 21.4 A Digression on Transitivity 289 optimized for readability and an algorithmic presentation that corresponds more or less directly to an implementation. In simple systems, the two pre- sentations are fairly similar; in more complex systems, they can be quite dif- ferent, and proving that they define the same relation on types can pose a significant challenge. (We will see an example of this in Chapter 28; many others have been studied.) One of the most distinctive differences between declarative and algorithmic presentations is that declarative presentations include an explicit rule of tran- sitivity—if S<:U and U<:T then S<:T—while algorithmic systems do not. This rule is useless in an algorithm, since applying it in a goal-directed manner would involve guessing U. The rule of transitivity plays two useful roles in declarative systems. First, it makes it obvious to the reader that the subtype relation is, indeed, tran- sitive. Second, transitivity often allows other rules to be stated in simpler, more primitive forms; in algorithmic presentations, these simple rules need to be combined into heavier mega-rules that take into account all possible combinations of the simpler ones. For example, in the presence of transitiv- ity, the rules for “depth subtyping” within record fields, “width subtyping” by adding new fields, and “permutation” of fields can be stated separately, making them all easier to understand, as we did in §15.2. Without transitiv- ity, the three rules must be merged into a single one that takes width, depth, and permutation into account all at once, as we did in §16.1. Somewhat surprisingly, the possibility of giving a declarative presentation with the rule of transitivity turns out to be a consequence of a “trick” that can be played with inductive, but not coinductive, definitions. To see why, observe that the property of transitivity is a closure property—it demands that the subtype relation be closed under the transitivity rule. Since the sub- type relation for finite types is itself defined as the closure of a set of rules, we can achieve closure under transitivity simply by adding it to the other rules. This is a general property of inductive definitions and closure proper- ties: the union of two sets of rules, when applied inductively, generates the least relation that is closed under both sets of rules separately. This fact can be formulated more abstractly in terms of generating functions: 21.4.1 Proposition: Suppose F and G are monotone functions, and let H(X) = F(X)∪G(X). Then µH is the smallest set that is both F-closed and G-closed. � Proof: First, we show that µH is closed under both F and G. By definition, µH = H(µH) = F(µH) ∪ G(µH), so F(µH) ⊆ µH and G(µH) ⊆ µH. Second, we show that µH is the least set closed under both F and G. Suppose there is some setX such that F(X) ⊆ X andG(X) ⊆ X. ThenH(X) = F(X)∪G(X) ⊆ X, 290 21 Metatheory of Recursive Types that is,X isH-closed. Since µH is the leastH-closed set (by the Knaster-Tarski theorem), we have µH ⊆ X. � Unfortunately, this trick for achieving transitive closure does not work when we are dealing with coinductive definitions. As the following exercise shows, adding transitivity to the rules generating a coinductively defined re- lation always gives us a degenerate relation. 21.4.2 Exercise [«]: Suppose F is a generating function on the universe U. Show that the greatest fixed point νFTR of the generating function FTR(R) = F(R) ∪ TR(R) is the total relation on U×U. � In the coinductive setting, then, we drop declarative presentations and work just with algorithmic ones. 21.5 Membership Checking We now turn our attention to the central question of the chapter: how to decide, given a generating function F on some universe U and an element x ∈ U, whether or not x falls in the greatest fixed point of F . Membership checking for least fixed points is addressed more briefly (in Exercise 21.5.13). A given element x ∈ U can, in general, be generated by F in many ways. That is, there can be more than one set X ⊆ U such that x ∈ F(X). Call any such set X a generating set for x. Because of the monotonicity of F , any superset of a generating set for x is also a generating set for x, so it makes sense to restrict our attention to minimal generating sets. Going one step further, we can focus on the class of “invertible” generating functions, where each x has at most one minimal generating set. 21.5.1 Definition: A generating function F is said to be invertible if, for all x ∈ U, the collection of sets Gx = {X ⊆ U|x ∈ F(X)} either is empty or contains a unique member that is a subset of all the others. When F is invertible, the partial function supportF ∈ U⇀ P(U) is defined as follows: supportF(x) = { X if X ∈ Gx and ∀X ′ ∈ Gx. X ⊆ X ′ ↑ if Gx = ∅ 21.5 Membership Checking 291 The support function is lifted to sets as follows: supportF (X) = { ⋃ x∈X supportF(x) if ∀x ∈ X. supportF (x)↓ ↑ otherwise When F is clear from context, we will often omit the subscript in supportF (and similar functions based on F that we define later). � 21.5.2 Exercise [««]: Verify that Sf and S , the generating functions for the subtyp- ing relations from Definitions 21.3.1 and 21.3.2, are invertible, and give their support functions. � Our goal is to develop algorithms for checking membership in the least and greatest fixed points of a generating function F . The basic steps in these algorithms will involve “running F backwards”: to check membership for an element x, we need to ask how x could have been generated by F . The advan- tage of an invertible F is that there is at most one way to generate a given x. For a non-invertible F , elements can be generated in multiple ways, lead- ing to a combinatorial explosion in the number of paths that the algorithm must explore. From now on, we restrict our attention to invertible generating functions. 21.5.3 Definition: An element x is F-supported if supportF(x)↓; otherwise, x is F- unsupported. An F-supported element is called F-ground if supportF(x) = ∅. � Note that an unsupported element x does not appear in F(X) for any X, while a ground x is in F(X) for every X. An invertible function can be visualized as a support graph. For exam- ple, Figure 21-2 defines a function E on the universe {a,b, c, d, e, f , g, h, i} by showing which elements are needed to support a given element of the uni- verse: for a given x, the set supportE(x) contains every y for which there is an arrow from x to y . An unsupported element is denoted by a slashed circle. In this example, i is the only unsupported element and g is the only ground element. (Note that, according to our definition, h is supported, even though its support set includes an unsupported element.) 21.5.4 Exercise [«]: Give inference rules corresponding to this function, as we did in Example 21.1.3. Check that E({b, c}) = {g,a, d}, that E({a, i}) = {g,h}, and that the sets of elements marked in the figure as µE and νE are indeed the least and the greatest fixed points of E. � Thinking about the graph in Figure 21-2 suggests the idea that an element x is in the greatest fixed point iff no unsupported element is reachable from 292 21 Metatheory of Recursive Types i d b e νE µE g c f h a Figure 21-2: A sample support function x in the support graph. This suggests an algorithmic strategy for checking whether x is in νF : enumerate all elements reachable from x via the support function; return failure if an unsupported element occurs in the enumeration; otherwise, succeed. Observe, however, that there can be cycles of reachability between the elements, and the enumeration procedure must take some pre- cautions against falling into an infinite loop. We will pursue this idea for the remainder of this section. 21.5.5 Definition: Suppose F is an invertible generating function. Define the boolean- valued function gfpF (or just gfp) as follows: gfp(X) = if support(X) ↑, then false else if support(X) ⊆ X, then true else gfp(support(X)∪X). Intuitively, gfp starts from X and keeps enriching it using support until either it becomes consistent or else an unsupported element is found. We extend gfp to individual elements by taking gfp(x) = gfp({x}). � 21.5.6 Exercise [«]: Another observation that can be made from Figure 21-2 is that an element x of νF is not a member of µF if x participates in a cycle in the support graph (or if there is a path from x to an element that participates in a cycle). Is the converse also true—that is, if x is a member of νF but not µF , is it necessarily the case that x leads to a cycle? � The remainder of the section is devoted to proving the correctness and termination of gfp. (First-time readers may want to skip this material and 21.5 Membership Checking 293 jump to the next section.) We start by observing a couple of properties of the support function. 21.5.7 Lemma: X ⊆ F(Y) iff supportF(X)↓ and supportF(X) ⊆ Y . � Proof: It suffices to show that x ∈ F(Y) iff support(x)↓ and support(x) ⊆ Y . Suppose first that x ∈ F(Y). Then Y ∈ Gx = {X ⊆ U|x ∈ F(X)}—that is, Gx ≠ ∅. Therefore, since F is invertible, support(x), the smallest set in Gx, exists and support(x) ⊆ Y . Conversely, if support(x) ⊆ Y , then F(support(x)) ⊆ F(Y) by monotonicity. But x ∈ F(support(x)) by the definition of support , so x ∈ F(Y). � 21.5.8 Lemma: Suppose P is a fixed point of F . Then X ⊆ P iff supportF (X)↓ and supportF(X) ⊆ P . � Proof: Recall that P = F(P) and apply Lemma 21.5.7. � Now we can prove partial correctness of gfp. (We are not concerned with to- tal correctness yet, because some generating functions will make gfp diverge. We prove termination for a restricted class of generating functions later in the section.) 21.5.9 Theorem: 1. If gfpF(X) = true, then X ⊆ νF . 2. If gfpF(X) = false, then X 6⊆ νF . � Proof: The proof of each clause proceeds by induction on the recursive struc- ture of a run of the algorithm. 1. From the definition of gfp, it is easy to see that there are two cases where gfp(X) can return true. If gfp(X) = true because support(X) ⊆ X, then, by Lemma 21.5.7, we have X ⊆ F(X), i.e., X is F-consistent; thus, X ⊆ νF by the coinduction principle. On the other hand, if gfp(X) = true be- cause gfp(support(X) ∪ X) = true, then, by the induction hypothesis, support(X)∪X ⊆ νF , and so X ⊆ νF . 2. Again, there are two ways to get gfp(X) = false. Suppose first that gfp(X) = false because support(X) ↑. Then X 6⊆ νF by Lemma 21.5.8. On the other hand, suppose gfp(X) = false because gfp(support(X) ∪ X) = false. By the induction hypothesis, support(X) ∪ X 6⊆ νF . Equivalently, X 6⊆ νF or support(X) 6⊆ νF . Either way, X 6⊆ νF (using Lemma 21.5.8 in the second case). � 294 21 Metatheory of Recursive Types Next, we identify a sufficient termination condition for gfp, giving a class of generating functions for which the algorithm is guaranteed to terminate. To describe the class, we need some additional terminology. 21.5.10 Definition: Given an invertible generating function F and an element x ∈ U, the set predF (x) (or just pred(x)) of immediate predecessors of x is pred(x) = { ∅ if support(x) ↑ support(x) if support(x)↓ and its extension to sets X ⊆ U is pred(X) = ⋃ x∈X pred(x). The set reachableF(X) (or just reachable(X)) of all elements reachable from a set X via support is defined as reachable(X) = ⋃ n≥0 pred n (X). and its extension to single elements x ∈ U is reachable(x) = reachable({x}). An element y ∈ U is reachable from an element x if y ∈ reachable(x). � 21.5.11 Definition: An invertible generating function F is said to be finite state if reachable(x) is finite for each x ∈ U. � For a finite-state generating function, the search space explored by gfp is finite and gfp always terminates: 21.5.12 Theorem: If reachableF (X) is finite, then gfpF(X) is defined. Consequently, if F is finite state, then gfpF (X) terminates for any finite X ⊆ U. � Proof: For each recursive call gfp(Y) in the call graph generated by the orig- inal invocation gfp(X), we have Y ⊆ reachable(X). Moreover, Y strictly in- creases on each call. Since reachable(X) is finite, m(Y) = |reachable(X)| − |Y | serves as a termination measure for gfp. � 21.5.13 Exercise [«««]: Suppose F is an invertible generating function. Define the function lfpF (or just lfp) as follows: lfp(X) = if support(X) ↑, then false else if X = ∅, then true else lfp(support(X)). 21.6 More Efficient Algorithms 295 Intuitively, lfp works by starting with a set X and using the support relation to reduce it until it becomes empty. Prove that this algorithm is partially correct, in the sense that 1. If lfpF(X) = true, then X ⊆ µF . 2. If lfpF(X) = false, then X 6⊆ µF . Can you find a class of generating functions for which lfpF is guaranteed to terminate on all finite inputs? � 21.6 More Efficient Algorithms Although the gfp algorithm is correct, it is not very efficient, since it has to recompute the support of the whole set X every time it makes a recursive call. For example, in the following trace of gfp on the function E from Figure 21-2, gfp({a}) = gfp({a,b, c}) = gfp({a,b, c, e, f , g}) = gfp({a,b, c, e, f , g, d}) = true. Note that support(a) is recomputed four times. We can refine the algorithm to eliminate this redundant recomputation by maintaining a set A of assump- tions whose support sets have already been considered and a set X of goals whose support has not yet been considered. 21.6.1 Definition: Suppose F is an invertible generating function. Define the func- tion gfp a F (or just gfp a ) as follows (the superscript “a” is for “assumptions”): gfp a (A,X) = if support(X) ↑, then false else if X = ∅, then true else gfp a (A∪X, support(X) \ (A∪X)). In order to check x ∈ νF , compute gfp a (∅, {x}). � This algorithm (like the two following algorithms in this section) computes the support of each element at most once. A trace for the above example looks like this: gfp a (∅, {a}) = gfp a ({a}, {b, c}) = gfp a ({a,b, c}, {e, f , g}) = gfp a ({a,b, c, e, f , g}, {d}) = gfp a ({a,b, c, e, f , g, d}, ∅) = true. 296 21 Metatheory of Recursive Types Naturally, the correctness statement for this algorithm is slightly more elaborate than the one we saw in the previous section. 21.6.2 Theorem: 1. If supportF(A) ⊆ A∪X and gfp a F (A,X) = true, then A∪X ⊆ νF . 2. If gfp a F(A,X) = false, then X 6⊆ νF . � Proof: Similar to 21.5.9. � The remainder of this section examines two more variations on the gfp algorithm that correspond more closely to well-known subtyping algorithms for recursive types. First-time readers may want to skip to the beginning of the next section. 21.6.3 Definition: A small variation on gfp a has the algorithm pick just one ele- ment at a time from X and expand its support . The new algorithm is called gfp s F (or just gfp s , “s” being for “single”). gfp s (A,X) = if X = ∅, then true else let x be some element of X in if x ∈ A then gfp s (A, X \ {x}) else if support(x) ↑ then false else gfp s (A∪ {x}, (X ∪ support(x)) \ (A∪ {x})). The correctness statement (i.e., the invariant of the recursive “loop”) for this algorithm is exactly the same as Theorem 21.6.2. Unlike the above algorithm, many existing algorithms for recursive sub- typing take just one candidate element, rather than a set, as an argument. Another small modification to our algorithm makes it more similar to these. The modified algorithm is no longer tail recursive,2 since it uses the call stack to remember subgoals that have not yet been checked. Another change is that the algorithm both takes a set of assumptions A as an argument and returns a new set of assumptions as a result. This allows it to record the subtyp- ing assumptions that have been generated during completed recursive calls and reuse them in later calls. In effect, the set of assumptions is “threaded” through the recursive call graph—whence the name of the algorithm, gfp t . 2. A tail-recursive call (or tail call) is a recursive call that is the last action of the calling function—i.e., such that the result returned from the recursive call will also be caller’s result. Tail calls are interesting because most compilers for functional languages will implement a tail call as a simple branch, re-using the stack space of the caller instead of allocating a new stack frame for the recursive call. This means that a loop implemented as a tail-recursive function compiles into the same machine code as an equivalent while loop. 21.6 More Efficient Algorithms 297 21.6.4 Definition: Given an invertible generating function F , define the function gfp t F (or just gfp t ) as follows: gfp t (A, x) = if x ∈ A, then A else if support(x) ↑, then fail else let {x1, . . . , xn} = support(x) in let A0 = A∪ {x} in let A1 = gfp t (A0, x1) in . . . let An = gfp t (An−1, xn) in An. To check x ∈ νF , compute gfp t (∅, x). If this call succeeds, then x ∈ νF ; if it fails, then x 6∈ νF . We use the following convention for failure: if an expression B fails, then “let A = B in C” also fails. This avoids writing explicit “exception handling” clauses for every recursive invocation of gfp t . � The correctness statement for this algorithm must again be refined from what we had above, taking into account the non-tail-recursive nature of this formulation by positing an extra “stack” X of elements whose supports re- main to be checked. 21.6.5 Lemma: 1. If gfp t F(A, x) = A ′, then A∪ {x} ⊆ A′. 2. For allX, if supportF(A) ⊆ A∪X∪{x} and gfp t F(A, x) = A ′, then supportF(A ′) ⊆ A′ ∪X. � Proof: Part (1) is a routine induction on the recursive structure of a run of the algorithm. Part (2) also goes by induction on the recursive structure of a run of the algorithm. If x ∈ A, then A′ = A and the desired conclusion follows immedi- ately from the assumption. On the other hand, suppose A′ ≠ A, and consider the special case where support(x) contains two elements x1 and x2—the gen- eral case (not shown here) is proved similarly, using an inner induction on the size of support(x). The algorithm calculates A0, A1, and A2 and returns A2. We want to show, for an arbitrary X0, that if support(A) ⊆ A ∪ {x} ∪ X0, then support(A2) ⊆ A2 ∪X0. Let X1 = X0 ∪ {x2}. Since support(A0) = support(A) ∪ support(x) = support(A) ∪ {x1, x2} ⊆ A∪ {x} ∪X0 ∪ {x1, x2} = A0 ∪X0 ∪ {x1, x2} = A0 ∪X1 ∪ {x1}, 298 21 Metatheory of Recursive Types we can apply the induction hypothesis to the first recursive call by instantiat- ing the universally quantified X with X1. This yields support(A1) ⊆ A1∪X1 = A1 ∪ {x2} ∪ X0. Now, we can apply the induction hypothesis to the second recursive call by instantiating the universally quantified X with X0 to obtain the desired result: support(A2) ⊆ A2 ∪X0. � 21.6.6 Theorem: 1. If gfp t F(∅, x) = A ′, then x ∈ νF . 2. If gfp t F(∅, x) = fail, then x ∉ νF . � Proof: For part (1), observe that, by Lemma 21.6.5(1), x ∈ A′. Instantiating part (2) of the lemma with X = ∅, we obtain support(A′) ⊆ A′—that is, A′ is F-consistent by Lemma 21.5.7, and so A′ ⊆ νF by coinduction. For part (2), we argue (by an easy induction on the depth of a run of the gfp t F algorithm, using Lemma 21.5.8) that if, for some A, we have gfp t F(A, x) = fail, then x ∉ νF . � Since all of the algorithms in this section examine the reachable set, a suffi- cient termination condition for all of them is the same as that of the original gfp algorithm: they terminate on all inputs when F is finite state. 21.7 Regular Trees At this point, we have developed generic algorithms for checking member- ship in a set defined as the greatest fixed point of a generating function F , assuming that F is invertible and finite state; separately, we have shown how to define subtyping between infinite trees as the greatest fixed point of a par- ticular generating function S . The obvious next step is to instantiate one of our algorithms with S . Of course, this concrete algorithm will not terminate on all inputs, since in general the set of states reachable from a given pair of infinite types can be infinite. But, as we shall see in this section, if we restrict ourselves to infinite types of a certain well-behaved form, so-called regular types, then the sets of reachable states will be guaranteed to remain finite and the subtype checking algorithm will always terminate. 21.7.1 Definition: A tree type S is a subtree of a tree type T if S = λσ. T(π,σ) for some π—that is, if the function S from paths to symbols can be obtained from the function T by adding some constant prefix π to the argument paths we give to T; the prefix π corresponds to the path from the root of T to the root of S. We write subtrees(T) for the set of all subtrees of T. � 21.7.2 Definition: A tree type T ∈ T is regular if subtrees(T) is finite—i.e., if T has finitely many distinct subtrees. The set of regular tree types is written Tr . � 21.8 µ-Types 299 21.7.3 Examples: 1. Every finite tree type is regular; the number of distinct subtrees is at most the number of nodes. The number of distinct subtrees of a tree type can be strictly less than the number of nodes. For example, T = Top→(Top×Top) has five nodes but only three distinct subtrees (T itself, Top× Top, and Top). 2. Some infinite tree types are regular. For example, the tree T = Top × (Top × (Top × ...)) has just two distinct subtrees (T itself and Top). 3. The tree type T = B×(A×(B×(A× (A×(B×(A×(A× (A×(B×...) where pairs of consecutive Bs are separated by increasingly many As, is not regular. Because T is irregular, the set reachableS(T,T) containing all the subtyping pairs needed to justify the statement T<:T is infinite. � 21.7.4 Proposition: The restriction Sr of the generating function S to regular tree types is finite state. � Proof: We need to show that for any pair (S,T) of regular tree types, the set reachableSr (S,T) is finite. Observe that reachableSr (S,T) ⊆ subtrees(S) × subtrees(T); the latter is finite, since both subtrees(S) and subtrees(T) are. � This means that we can obtain a decision procedure for the subtype rela- tion on regular tree types by instantiating one of the membership algorithms with S . Naturally, for this to work in a practical implementation, regular trees must be represented by some finite structures. One such representation, µ- notation, is discussed in the next section. 21.8 µ-Types This section develops the finite µ-notation, defines subtyping on µ-expressions, and establishes the correspondence between this notion of subtyping and the subtyping on tree types. 21.8.1 Definition: Let X range over a fixed countable set {X1,X2, . . .} of type vari- ables. The set T rawm of raw µ-types is the set of expressions defined by the following grammar: 300 21 Metatheory of Recursive Types T ::= X Top T×T T→T µX.T The syntactic operator µ is a binder, and gives rise, in the standard way, to notions of bound and free variables, closed raw µ-types, and equivalence of raw µ-types up to renaming of bound variables. FV(T) denotes the set of free variables of a raw µ-type T. The capture-avoiding substitution [X , S]T of a raw µ-type S for free occurrences of X in a raw µ-type T is defined as usual. � Raw µ-types have to be restricted a little to achieve a tight correspondence with regular trees: we want to be able to “read off” a tree type as the infinite unfolding of a given µ-type, but there are raw µ-types that cannot be rea- sonably interpreted as representations of tree types. These types have subex- pressions of the form µX.µX1...µXn.X, where the variables X1 through Xn are distinct from X. For example, consider T = µX.X. Unfolding of T gives T again, so we cannot read off any tree by unfolding T. This leads us to the following restriction. 21.8.2 Definition: A raw µ-type T is contractive if, for any subexpression of T of the form µX.µX1...µXn.S, the body S is not X. Equivalently, a raw µ-type is contractive if every occurrence of a µ-bound variable in the body is separated from its binder by at least one → or × . A raw µ-type is called simply a µ-type if it is contractive. The set of µ-types is written Tm. When T is a µ-type, we write µ-height(T) for the number of µ-bindings at the front of T. � The common understanding of µ-types as finite notation for infinite regular tree types is formalized by the following function. 21.8.3 Definition: The function treeof , mapping closed µ-types to tree types, is defined inductively as follows: treeof (Top)(•) = Top treeof (T1→T2)(•) = → treeof (T1→T2)(i,π) = treeof (Ti)(π) treeof (T1×T2)(•) = × treeof (T1×T2)(i,π) = treeof (Ti)(π) treeof (µX.T)(π) = treeof ([X, µX.T]T)(π) 21.8 µ-Types 301 . . . . . . . . . . . . × Top → →× Top × Top treeof (µX.((X×Top)→X)) = 11 2 1 2 2 1 2 21 21 → Figure 21-3: Sample treeof application To verify that this definition is proper (i.e., exhaustive and terminating), note the following: 1. Every recursive use of treeof on the right-hand side reduces the lexico- graphic size of the pair (|π|, µ-height(T)): the cases for S→T and S×T reduce |π| and the case for µX.T preserves |π| but reduces µ-height(T). 2. All recursive calls preserve contractiveness and closure of the argument types. In particular, the type µX.T is contractive and closed iff its unfold- ing [X , µX.T]T is. This justifies the unfolding step in the definition of treeof (µX.T). The treeof function is lifted to pairs of types by defining treeof (S,T) = (treeof (S), treeof (T)). � An sample application of treeof to a µ-type is shown in Figure 21-3. The subtype relation for tree types was defined in §21.3 as the greatest fixed point of the generating function S . In the present section, we extended the syntax of types with µ-types, whose behavior is intuitively described by the rules of (right and left, correspondingly) µ-folding: S <: [X, µX.T]T S <: µX.T and [X, µX.S]S <: T µX.S <: T Formally, we define subtyping for µ-types by giving a generating function Sm, with three clauses identical to the definition of S and two additional clauses corresponding to the µ-folding rules. 302 21 Metatheory of Recursive Types 21.8.4 Definition: Two µ-types S and T are said to be in the subtype relation if (S,T) ∈ νSm, where the monotone function Sm ∈ P(Tm×Tm)→ P(Tm×Tm) is defined by: Sm(R) = {(S,Top) | S ∈ Tm} ∪ {(S1×S2,T1×T2) | (S1,T1), (S2,T2) ∈ R} ∪ {(S1→S2,T1→T2) | (T1,S1), (S2,T2) ∈ R} ∪ {(S, µX.T) | (S, [X, µX.T]T) ∈ R} ∪ {(µX.S,T) | ([X, µX.S]S,T) ∈ R, T ≠ Top, and T ≠ µY.T1}. Note that this definition does not embody precisely the µ-folding rules above: we have introduced an asymmetry between its final and penultimate clauses to make it invertible (otherwise, the clauses would overlap). However, as the next exercise shows, Sm generates the same subtype relation as the more natural generating function3 Sd whose clauses exactly correspond to the in- ference rules. � 21.8.5 Exercise [«««]: Write down the function Sd mentioned above, and demon- strate that it is not invertible. Prove that νSd = νSm. � The generating function Sm is invertible because the corresponding sup- port function is well-defined: supportSm(S,T) =                    ∅ if T = Top {(S1,T1), (S2,T2)} if S = S1×S2 and T = T1×T2 {(T1,S1), (S2,T2)} if S = S1→S2 and T = T1→T2 {(S, [X, µX.T1]T1)} if T = µX.T1 {([X, µX.S1]S1,T)} if S = µX.S1 and T ≠ µX.T1, T ≠ Top ↑ otherwise. The subtype relation on µ-types so far has been introduced independently of the previously defined subtyping on tree types. Since we think of µ-types as just a way of representing regular types in a finite form, it is necessary to ensure that the two notions of subtyping correspond to each other. The next theorem (21.8.7) establishes this correspondence. But first, we need a technical lemma. 21.8.6 Lemma: Suppose that R ⊆ Tm×Tm is Sm-consistent. For any (S,T) ∈ R, there is some (S′,T′) ∈ R such that treeof (S′,T′) = treeof (S,T) and neither S′ nor T′ starts with µ. � 3. The “d” in Sd is a reminder that the function is based on the “declarative” inference rules for µ-folding, in contrast to the “algorithmic” versions used in Sm . 21.8 µ-Types 303 Proof: By induction on the total number of µs at the front of S and T. If neither S nor T starts with µ, then we can take (S′,T′) = (S,T). On the other hand, if (S,T) = (S, µX.T1), then by the Sm-consistency of R, we have (S,T) ∈ Sm(R), so (S ′′,T′′) = (S, [X, µX.T1]T1) ∈ R. Since T is contractive, the result T′′ of unfolding T has one fewer µ at the front than T does. By the induction hypothesis, there is some (S′,T′) ∈ R such that neither S′ nor T′ starts with µ and such that treeof (S′′,T′′) = (S′,T′). Since, by the definition of treeof , treeof (S,T) = treeof (S′′,T′′), the pair (S′,T′) is the one we need. The case where (S,T) = (µX.S1,T) is similar. � 21.8.7 Theorem: Let (S,T) ∈ Tm ×Tm. Then (S,T) ∈ νSm iff treeof (S,T) ∈ νS . � Proof: First, let us consider the “only if” direction—that (S,T) ∈ νSm implies treeof (S,T) ∈ νS . Let (A,B) = treeof (S,T) ∈ T × T . By the coinduction prin- ciple, the result will follow if we can exhibit an S-consistent set Q ∈ T × T such that (A,B) ∈ Q. Our claim is that Q = treeof (νSm) is such a set. To verify this, we must show that (A′,B′) ∈ S(Q) for every (A′,B′) ∈ Q. Let (S′,T′) ∈ νSm be a pair of µ-types such that treeof (S ′,T′) = (A′,B′). By Lemma 21.8.6, we may assume that neither S′ nor T′ starts with µ. Since νSm is Sm-consistent, (S ′,T′) must be supported by one of the clauses in the definition of Sm—i.e., it must have one of the following shapes. Case: (S′,T′) = (S′,Top) Then B′ = Top, and (A′,B′) ∈ S(Q) by the definition of S . Case: (S′,T′) = (S1×S2,T1×T2) with (S1,T1), (S2,T2) ∈ νSm By the definition of treeof , we have B′ = treeof (T′) = B1×B2, where each Bi = treeof (Ti). Similarly, A ′ = A1×A2, where Ai = treeof (Si). Applying treeof to these pairs gives (A1,B1), (A2,B2) ∈ Q. But then, by the definition of S , we have (A,B) = (A1×A2,B1×B2) ∈ S(Q). Case: (S′,T′) = (S1→S2,T1→T2) with (T1,S1), (S2,T2) ∈ νSm Similar. Next, let us check the “if” direction of the theorem—that treeof (S,T) ∈ νS implies (S,T) ∈ νSm. By the coinduction principle, it suffices to exhibit an Sm-consistent set R ∈ Tm × Tm with (S,T) ∈ R. We claim that R = {(S ′,T′) ∈ Tm × Tm | treeof (S ′,T′) ∈ νS}. Clearly, (S,T) ∈ R. To finish the proof, we must now show that (S′,T′) ∈ R implies (S′,T′) ∈ Sm(R). Note that, since νS is S-consistent, any pair (A′,B′) ∈ νS must have one of the forms (A′,Top), (A1×A2,B1×B2), or (A1→A2,B1→B2). From this and the definition of treeof , we see that any pair (S′,T′) ∈ R must have one of the forms (S′,Top), (S1×S2,T1×T2), (S1→S2,T1→T2), (S ′, µX.T1), or (µX.S1,T ′). We consider each of these cases in turn. 304 21 Metatheory of Recursive Types Case: (S′,T′) = (S′,Top) Then (S′,T′) ∈ Sm(R) immediately, by the definition of Sm. Case: (S′,T′) = (S1×S2,T1×T2) Let (A′,B′) = treeof (S′,T′). Then (A′,B′) = (A1×A2,B1×B2), with Ai = treeof (Si) and Bi = treeof (Ti). Since (A ′,B′) ∈ νS , the S-consistency of νS implies that (Ai,Bi) ∈ νS , which in turn yields (Si ,Ti) ∈ R, by the definition of R. The definition of Sm yields (S ′,T′) = (S1×S2,T1×T2) ∈ Sm(R). Case: (S′,T′) = (S1→S2,T1→T2) Similar. Case: (S′,T′) = (S′, µX.T1) Let T′′ = [X , µX.T1]T1. By definition, treeof (T ′′) = treeof (T′). Therefore, by the definition of R, we have (S′,T′′) ∈ R, and so (S′,T′) ∈ Sm(R), by the definition of Sm. Case: (S′,T′) = (µX.S1,T ′) If T′ = Top or T′ starts with µ, then one of the cases above applies; otherwise, the argument is similar to the previous one. � The correspondence established by the theorem is a statement of sound- ness and completeness of subtyping between µ-types, as defined in this sec- tion, with respect to the ordinary subtype relation between infinite tree types, restricted to those tree types that can be represented by finite µ-expressions. 21.9 Counting Subexpressions Instantiating the generic algorithm gfp t (21.6.4) with the specific support function supportSm for the subtype relation on µ-types (21.8.4) yields the sub- typing algorithm shown in Figure 21-4. The argument in Section 21.6 shows that the termination of this algorithm can be guaranteed if reachableSm(S,T) is finite for any pair of µ-types (S,T). The present section is devoted to prov- ing that this is the case (Proposition 21.9.11). At first glance, the property seems almost obvious, but proving it rigor- ously requires a surprising amount of work. The difficulty is that there are two possible ways of defining the set of “closed subexpressions” of a µ- type. One, which we call top-down subexpressions, directly corresponds to the subexpressions generated by support Sm . The other, called bottom-up subex- pressions, supports a straightforward proof that the set of closed subex- pressions of every closed µ-type is finite. The termination proof proceeds by defining both of these sets and showing that the former is a subset of the 21.9 Counting Subexpressions 305 subtype(A,S,T) = if (S,T) ∈ A, then A else let A0 = A∪ {(S,T)} in if T = Top, then A0 else if S = S1×S2 and T = T1×T2, then let A1 = subtype(A0,S1,T1) in subtype(A1,S2,T2) else if S = S1→S2 and T = T1→T2, then let A1 = subtype(A0,T1,S1) in subtype(A1,S2,T2) else if T = µX.T1, then subtype(A0, S, [X, µX.T1]T1) else if S = µX.S1, then subtype(A0, [X, µX.S1]S1, T) else fail Figure 21-4: Concrete subtyping algorithm for µ-types latter (Proposition 21.9.10). The development here is based on Brandt and Henglein’s (1997). 21.9.1 Definition: A µ-type S is a top-down subexpression of a µ-type T, written S v T, if the pair (S,T) is in the least fixed point of the following generating function: TD(R) = {(T,T) | T ∈ Tm} ∪ {(S,T1×T2) | (S,T1) ∈ R} ∪ {(S,T1×T2) | (S,T2) ∈ R} ∪ {(S,T1→T2) | (S,T1) ∈ R} ∪ {(S,T1→T2) | (S,T2) ∈ R} ∪ {(S, µX.T) | (S, [X, µX.T]T) ∈ R} 21.9.2 Exercise [«]: Give an equivalent definition of the relation S v T as a set of inference rules. � From the definition of supportSm it is easy to see that, for any µ-types S and T, all the pairs contained in supportSm(S,T) are formed from top-down subexpressions of S and T: 21.9.3 Lemma: If (S′,T′) ∈ supportSm(S,T), then either S ′ v S or S′ v T, and either T′ v S or T′ v T. � 306 21 Metatheory of Recursive Types Proof: Straightforward inspection of the definition of supportSm . � Also, the top-down subexpression relation is transitive: 21.9.4 Lemma: If S v U and U v T, then S v T. � Proof: The statement of the lemma is equivalent to ∀U,T. U v T⇒ (∀S. S v U ⇒ S v T). In other words, we must show that µ(TD) ⊆ R, where R = {(U,T) | ∀S. S v U ⇒ S v T}. By the induction principle, it suffices to show that R is TD-closed—that is, that TD(R) ⊆ R. So suppose (U,T) ∈ TD(R). Proceed by cases on the clauses in the definition of TD. Case: (U,T) = (T,T) Clearly, (T,T) ∈ R. Case: (U,T) = (U,T1×T2) and (U,T1) ∈ R Since (U,T1) ∈ R, it must be the case that S v U ⇒ S v T1 for all S. By the definition of v, it must also be the case that S v U ⇒ S v T1×T2 for all S. Thus, (U,T) = (U,T1×T2) ∈ R, by the definition of R. Other cases: Similar. � Combining the two previous lemmas gives us the proposition that moti- vates the introduction of top-down subexpressions: 21.9.5 Proposition: If (S′,T′) ∈ reachableSm(S,T), then S ′ v S or S′ v T, and T′ v S or T′ v T. � Proof: By induction on the definition of reachableSm , using transitivity of v. � The finiteness of reachableSm(S,T) will follow (in Proposition 21.9.11) from the above proposition and the fact that any µ-type U has only a finite num- ber of top-down subexpressions. Unfortunately, the latter fact is not obvious from the definition of v. Attempting to prove it by structural induction on U using the definition of TD does not work because the last clause of TD breaks the induction: to construct the subexpressions of U = µX.T, it refers to a potentially larger expression [X, µX.T]T. The alternative notion of bottom-up subexpressions avoids this problem by performing the substitution of µ-types for recursion variables after calcu- lating the subexpressions instead of before. This change will lead to a simple proof of finiteness. 21.9 Counting Subexpressions 307 21.9.6 Definition: A µ-type S is a bottom-up subexpression of a µ-type T, written S � T, if the pair (S,T) is in the least fixed point of the following generating function: BU(R) = {(T,T) | T ∈ Tm} ∪ {(S,T1×T2) | (S,T1) ∈ R} ∪ {(S,T1×T2) | (S,T2) ∈ R} ∪ {(S,T1→T2) | (S,T1) ∈ R} ∪ {(S,T1→T2) | (S,T2) ∈ R} ∪ {([X, µX.T]S, µX.T) | (S,T) ∈ R} This new definition of subexpressions differs from the old one only in the clause for a type starting with a µ binder. To obtain the top-down subex- pressions of such a type, we unfolded it first and then collected the subex- pressions of the unfolding. To obtain the bottom-up subexpressions, we first collect the (not necessarily closed) subexpressions of the body, and then close them by applying the unfolding substitution. 21.9.7 Exercise [««]: Give an equivalent definition of the relation S � T as a set of inference rules. � The fact that an expression has only finitely many bottom-up subexpres- sions is easily proved. 21.9.8 Lemma: {S | S � T} is finite for each T. � Proof: Straightforward structural induction on T, using the following obser- vations, which follow from the definition of BU and �: • if T = Top or T = X then {S | S � T} = {T}; • if T = T1×T2 or T = T1→T2 then {S | S � T} = {T}∪{S | S � T1}∪{S | S � T2}; • if T = µX.T′ then {S | S � T} = {T} ∪ {[X, T]S | S � T′}. � To prove that the bottom-up subexpressions of a type include its top-down subexpressions, we will need the following lemma relating bottom-up subex- pressions and substitution. 21.9.9 Lemma: If S � [X , Q]T, then either S � Q or else S = [X , Q]S′ for some S′ with S′ � T. � Proof: By structural induction on T. 308 21 Metatheory of Recursive Types Case: T = Top Only the reflexivity clause of BU allows Top as the right-hand element of the pair, so we must have S = Top. Taking S′ = Top yields the desired result. Case: T = Y If Y = X, we have S � [X , Q]T = Q, and the desired result holds by assump- tion. If Y ≠ X, we have S = [X , Q]T = Y. Only the reflexivity clause of BU can justify this pair, so we must have S = Y. Take S′ = Y to get the desired result. Case: T = T1×T2 We have S � [X, Q]T = [X, Q]T1× [X, Q]T2. According to the definition of BU, there are three ways in which S can be a bottom-up subexpression of this product type. We consider each in turn. Subcase: S = [X, Q]T Then take S′ = T. Subcase: S � [X, Q]T1 By the induction hypothesis, either S � Q (in which case we are done) or else S = [X , Q]S′ for some S′ � T1. The latter alternative implies the desired result S′ � T1×T2 by the definition of BU. Subcase: S � [X, Q]T2 Similar. Case: T = T1→T2 Similar to the product case. Case: T = µY.T′ We have S � [X , Q]T = µY.[X , Q]T′. There are two ways in which S can be a bottom-up subexpression of this µ-type. Subcase: S = [X, Q]T Take S′ = T Subcase: S = [Y, µY.[X, Q]T′]S1 with S1 � [X, Q]T ′ Applying the induction hypothesis gives us two possible alternatives: • S1 � Q. By our conventions on bound variable names, we know that Y ∉ FV(Q), so it must be that Y ∉ FV(S1). But then S = [Y , µY.[X , Q]T ′]S1 = S1, so S � Q. • S1 = [X , Q]S2 for some S2 such that S2 � T ′. In this case, S = [Y , µY.[X , Q]T′]S1 = [Y , µY.[X , Q]T ′][X , Q]S2 = [X , Q][Y , µY.T ′]S2. Take S′ = [Y, µY.S′]S2 to obtain the desired result. � 21.10 Digression: An Exponential Algorithm 309 The final piece of the proof establishes that every top-down subexpression of a µ-type can be found among its bottom-up subexpressions. 21.9.10 Proposition: If S v T, then S � T. � Proof: We want to show that µTD ⊆ µBU. By the principle of induction, this will follow if we can show that µBU is TD-closed—that is, TD(µBU) ⊆ µBU. In other words, we want to show that (A,B) ∈ TD(µBU) implies (A,B) ∈ µBU = BU(µBU). The latter will be true if every clause of TD that could have gen- erated (A,B) from µBU is matched by a clause of BU that also generates (A,B) from µBU. This is trivially true for all the clauses of TD except the last, since they are exactly the same as the corresponding clauses of BU. In the last clause, (A,B) = (S, µX.T) ∈ TD(µBU) and (S, [X , µX.T]T) ∈ µBU or, equivalently, S � [X , µX.T]T. By Lemma 21.9.9, either S � µX.T, which is (S, µX.T) ∈ µBU, what is needed, or S = [X , µX.T]S′ for some S′ with (S′,T) ∈ µBU. The latter implies (S, µX.T) ∈ BU(µBU) = µBU, by the last clause of BU. � Combining the facts established in this section gives us the final result. 21.9.11 Proposition: For any µ-types S and T, the set reachableSm(S,T) is finite. � Proof: For S and T, let Td be the set of all their top-down subexpressions, and Bu be the set of all their bottom-up subexpressions. According to Propo- sition 21.9.5, reachableSm(S,T) ⊆ Td × Td. By Proposition 21.9.10, Td× Td ⊆ Bu× Bu. By Lemma 21.9.8, the latter set is finite. Therefore, reachableSm(S,T) is finite. � 21.10 Digression: An Exponential Algorithm The algorithm subtype presented at the beginning of §21.9 (Figure 21-4) can be simplified a bit more by making it return just a boolean value rather than a new set of assumptions (see Figure 21-5). The resulting procedure, subtype ac , corresponds to Amadio and Cardelli’s algorithm for checking sub- typing (1993). It computes the same relation as the one computed by subtype, but much less efficiently because it does not remember pairs of types in the subtype relation across the recursive calls in the → and × cases. This seem- ingly innocent change results in a blowup of the number of recursive calls the algorithm makes. Whereas the number of recursive calls made by subtype is proportional to the square of the total number of subexpressions in the two argument types (as can be seen by inspecting the proofs of Lemma 21.9.8 and Proposition 21.9.11), in the case of subtype ac it is exponential. 310 21 Metatheory of Recursive Types subtype ac (A,S,T) = if (S,T) ∈ A, then true else let A0 = A∪ (S,T) in if T = Top, then true else if S = S1×S2 and T = T1×T2, then subtype ac (A0,S1,T1) and subtype ac (A0,S2,T2) else if S = S1→S2 and T = T1→T2, then subtype ac (A0,T1,S1) and subtype ac (A0,S2,T2) else if S = µX.S1, then subtype ac (A0, [X, µX.S1]S1, T) else if T = µX.T1, then subtype ac (A0, S, [X, µX.T1]T1) else false. Figure 21-5: Amadio and Cardelli’s subtyping algorithm The exponential behavior of subtype ac can be seen clearly in the following example. Define families of types Sn and Tn inductively as follows: S0 = µX.Top×X Sn+1 = µX.X→Sn T0 = µX.Top×(Top×X) Tn+1 = µX.X→Tn. Since Sn and Tn each contain just one occurrence of Sn−1 and Tn−1, respec- tively, their size (after expanding abbreviations) will be linear in n. Checking Sn <: Tn generates an exponential derivation, however, as can be seen by the following sequence of recursive calls subtype ac (∅,Sn,Tn) = subtype ac (A1,Sn→Sn−1,Tn) = subtype ac (A2,Sn→Sn−1,Tn→Tn−1) = subtype ac (A3,Tn,Sn) and subtype ac (A3,Sn−1,Tn−1) = subtype ac (A4,Tn→Tn−1,Sn) and . . . = subtype ac (A5,Tn→Tn−1,Sn→Sn−1) and . . . = subtype ac (A6,Sn,Tn) and subtype ac (A6,Tn−1,Sn−1) and . . . = etc., where A1 = {(Sn,Tn)} A2 = A1 ∪ {(Sn→Sn−1,Tn)} A3 = A2 ∪ {(Sn→Sn−1,Tn→Tn−1)} A4 = A3 ∪ {(Tn,Sn)} A5 = A4 ∪ {(Tn→Tn−1,Sn)} A6 = A5 ∪ {(Tn→Tn−1,Sn→Sn−1)}. 21.11 Subtyping Iso-Recursive Types 311 Notice that the initial call subtype ac (∅,Sn,Tn) results in the two underlined recursive calls of the same form involving Sn−1 and Tn−1. These, in turn, will each give rise to two recursive calls involving Sn−2 and Tn−2, and so on. The total number of recursive calls is thus proportional to 2n . 21.11 Subtyping Iso-Recursive Types We remarked in §20.2 that some treatments of recursive types adopt an iso- recursive presentation, where the folding and unfolding of recursive types is witnessed explicitly by the term constructors fold and unfold. In such languages, the µ type constructor is “rigid,” in the sense that its position in a type affects how terms belonging to this type can be used. If we add subtyping to a language with iso-recursive types, the rigidity of the µ constructor also affects the subtype relation. Instead of intuitively “un- rolling to the limit, then subtyping,” as we have done in most of this chapter, we must define subtyping rules involving recursive types directly. The most common definition of iso-recursive subtyping is the Amber rule— so-called because it was popularized by Cardelli’s Amber language (1986): Σ, X<:Y ` S <: T Σ ` µX.S <: µY.T (S-Amber) Intuitively, this rule can be read, “To show that µX.S is a subtype of µY.T under some set of assumptions Σ, it suffices to show S <: T under the ad- ditional assumption that X <: Y.”4 Σ here is just a set of pairs of recursion variables, recording the pairs of recursive types that have already been con- sidered. These assumptions are used by another subtyping rule (X <: Y) ∈ Σ Σ ` X <: Y (S-Assumption) that allows us to conclude X <: Y if we are currently assuming it. In effect, adding these two rules to the usual subtyping algorithm from Chapter 16 (and extending the other rules so that they pass Σ through from premises to conclusion) yields an algorithm that behaves somewhat like the subtype ac algorithm in Figure 21-5, with Σ playing the role of A. The differ- ences are that (1) we “unfold” recursive types only when they appear on both sides of the <: at once, and (2) we do not substitute the recursive types into their bodies (we just leave them as variables), which makes it easy to see that the algorithm terminates. 4. Note that this rule, unlike most rules involving binding constructs on both sides, such as S-All in Figure 26-1, demands that the bound variables X and Y be renamed to be distinct before the rule is applied. 312 21 Metatheory of Recursive Types The subtyping rules found in nominal type systems (such as Featherweight Java, Chapter 19) are closely related to the Amber rule. 21.11.1 Exercise [Recommended, ««]: Find recursive types S and T such that S <: T using the equi-recursive definition, but not using the Amber rule. � 21.12 Notes This chapter is based on a tutorial article by Gapeyev, Levin, and Pierce (2000). Background on coinduction can be found in Barwise and Moss’s Vicious Circles (1996), Gordon’s tutorial on coinduction and functional programming (1995), and Milner and Tofte’s expository article on coinduction in program- ming language semantics (1991a). For basic information on monotone func- tions and fixed points see Aczel (1977) and Davey and Priestley (1990). The use of coinductive proof methods in computer science dates from the 1970s, for example in the work of Milner (1980) and Park (1981) on con- currency; also see Arbib and Manes’s categorical discussion of duality in au- tomata theory (1975). But the use of induction in its dual “co-” form was familiar to mathematicians considerably earlier and is developed explicitly in, for example, universal algebra and category theory. Aczel’s seminal book (1988) on non-well-founded sets includes a brief historical survey. Amadio and Cardelli (1993) gave the first subtyping algorithm for recur- sive types. Their paper defines three relations: an inclusion relation between infinite trees, an algorithm that checks subtyping between µ-types, and a ref- erence subtype relation between µ-types defined as the least fixed point of a set of declarative inference rules; these relations are proved to be equiv- alent, and connected to a model construction based on partial equivalence relations. Coinduction is not used; instead, to reason about infinite trees, a notion of finite approximations of an infinite tree is introduced. This notion plays a key role in many of the proofs. Brandt and Henglein (1997) laid bare the underlying coinductive nature of Amadio and Cardelli’s system, giving a new inductive axiomatization of the subtype relation that is sound and complete with respect to that of Amadio and Cardelli. The so-called Arrow/Fix rule of the axiomatization embodies the coinductiveness of the system. The paper describes a general method for deriving an inductive axiomatization for relations that are naturally defined by coinduction and presents a detailed proof of termination for a subtyp- ing algorithm. §21.9 of the present chapter closely follows the latter proof. Brandt and Henglein establish that the complexity of their algorithm isO(n2). Kozen, Palsberg, and Schwartzbach (1993) obtain an elegant quadratic sub- typing algorithm by observing that a regular recursive type corresponds to 21.12 Notes 313 an automaton with labeled states. They define a product of two automata that yields a conventional word automaton accepting a word iff the types corresponding to the original automata are not in the subtype relation. A linear-time emptiness test now solves the subtyping problem. This fact, plus the quadratic complexity of product construction and linear-time conversion from types to automata, gives an overall quadratic complexity. Hosoya, Vouillon, and Pierce (2001) use a related automata-theoretic ap- proach, associating recursive types (with unions) to tree automata in a sub- typing algorithm tuned to XML processing applications. Jim and Palsberg (1999) address type reconstruction (see Chapter 22) for languages with subtyping and recursive types. As we have done in this chap- ter, they adopt a coinductive view of the subtype relation over infinite trees and motivate a subtype checking algorithm as a procedure building the min- imal simulation (i.e., consistent set, in our terminology) from a given pair of types. They define the notions of consistency and P1-closure of a relation over types, which correspond to our consistency and reachable sets. If you think about it long enough, you’ll see that it’s obvious. —Saul Gorn P a r t V Polymorphism 22 Type Reconstruction The typechecking algorithms for the calculi we have seen so far all depend on explicit type annotations—in particular, they require that lambda-abstractions be annotated with their argument types. In this chapter, we develop a more powerful type reconstruction algorithm, capable of calculating a principal type for a term in which some or all of these annotations are left unspecified. Re- lated algorithms lie at the heart of languages like ML and Haskell. Combining type reconstruction with other language features is often a somewhat delicate matter. In particular, both records and subtyping pose significant challenges. To keep things simple, we consider type reconstruc- tion here only for simple types; §22.8 gives some starting points for further reading on other combinations. 22.1 Type Variables and Substitutions In some of the calculi in previous chapters, we have assumed that the set of types includes an infinite collection of uninterpreted base types (§11.1). Unlike interpreted base types such as Bool and Nat, these types come with no operations for introducing or eliminating terms; intuitively, they are just placeholders for some particular types whose exact identities we do not care about. In this chapter, we will be asking questions like “if we instantiate the placeholder X in the term t with the concrete type Bool, do we obtain a ty- pable term?” In other words, we will treat our uninterpreted base types as type variables, which can be substituted or instantiated with other types. For the technical development in this chapter, it is convenient to separate the operation of substituting types for type variables into two parts: describ- ing a mapping σ from type variables to types, called a type substitution, and The system studied in this chapter is the simply typed lambda-calculus (Figure 9-1) with booleans (8-1), numbers (8-2), and an infinite collection of base types (11-1). The corresponding OCaml implementations are recon and fullrecon. 318 22 Type Reconstruction applying this mapping to a particular type T to obtain an instance σT. For example, we might define σ = [X , Bool] and then apply σ to the type X→X to obtain σ(X→X) = Bool→Bool. 22.1.1 Definition: Formally, a type substitution (or just substitution, when it’s clear that we’re talking about types) is a finite mapping from type variables to types. For example, we write [X , T, Y , U] for the substitution that asso- ciates X with T and Y with U. We write dom(σ) for the set of type variables appearing on the left-hand sides of pairs in σ , and range(σ) for the set of types appearing on the right-hand sides. Note that the same variable may occur in both the domain and the range of a substitution. Like term substitu- tions, the intention in such cases is that all the clauses of the substitution are applied simultaneously; for example, [X , Bool, Y , X→X] maps X to Bool and Y to X→X, not Bool→Bool. Application of a substitution to a type is defined in the obvious way: σ(X) = { T if (X, T) ∈ σ X if X is not in the domain of σ σ(Nat) = Nat σ(Bool) = Bool σ(T1→T2) = σT1 → σT2 Note that we do not need to make any special provisions to avoid variable cap- ture during type substitution, because there are no constructs in the language of type expressions that bind type variables. (We’ll get to these in Chapter 23.) Type substitution is extended pointwise to contexts by defining σ(x1:T1, . . . ,xn:Tn) = (x1:σT1, . . . ,xn:σTn). Similarly, a substitution is applied to a term t by applying it to all types appearing in annotations in t. If σ and γ are substitutions, we write σ ◦ γ for the substitution formed by composing them as follows: σ ◦ γ = [ X, σ(T) for each (X, T) ∈ γ X, T for each (X, T) ∈ σ with X ∉ dom(γ) ] Note that (σ ◦ γ)S = σ(γS). � A crucial property of type substitutions is that they preserve the validity of typing statements: if a term involving variables is well typed, then so are all of its substitution instances. 22.1.2 Theorem [Preservation of typing under type substitution]: If σ is any type substitution and Γ ` t : T, then σ Γ ` σt : σT. � Proof: Straightforward induction on typing derivations. � 22.2 Two Views of Type Variables 319 22.2 Two Views of Type Variables Suppose that t is a term containing type variables and Γ is an associated context (possibly also containing type variables). There are two quite different questions that we can ask about t: 1. “Are all substitution instances of t well typed?” That is, for every σ , do we have σ Γ ` σt : T for some T? 2. “Is some substitution instance of t well typed?” That is, can we find a σ such that σ Γ ` σt : T for some T? According to the first view, type variables should be held abstract during typechecking, thus ensuring that a well-typed term will behave properly no matter what concrete types are later substituted for its type variables. For example, the term λf:X→X. λa:X. f (f a); has type (X→X)→X→X, and, whenever we replace X by a concrete type T, the instance λf:T→T. λa:T. f (f a); is well typed. Holding type variables abstract in this way leads us to para- metric polymorphism, where type variables are used to encode the fact that a term can be used in many concrete contexts with different concrete types. We will return to parametric polymorphism later in this chapter (in §22.7) and, in more depth, in Chapter 23. On the second view, the original term t may not even be well typed; what we want to know is whether it can be instantiated to a well typed term by choosing appropriate values for some of its type variables. For example, the term λf:Y. λa:X. f (f a); is not typable as it stands, but if we replace Y by Nat→Nat and X by Nat, we obtain λf:Nat→Nat. λa:Nat. f (f a); of type (Nat→Nat)→Nat→Nat. Or, if we simply replace Y by X→X, we obtain the term λf:X→X. λa:X. f (f a); 320 22 Type Reconstruction which is well typed even though it contains variables. Indeed, this term is a most general instance of λf:Y. λa:X. f (f a), in the sense that it makes the smallest commitment about the values of type variables that yields a well- typed term. Looking for valid instantiations of type variables leads to the idea of type reconstruction (sometimes called type inference), in which the compiler helps fill in type information that has been left out by the programmer. In the limit, we may, as in ML, allow the programmer to leave out all type annotations and write in the syntax of the bare, untyped lambda-calculus. During parsing, we annotate each bare lambda-abstraction λx.t with a type variable, λx:X.t, choosing X to be different from the type variables on all the other abstractions in the program. We then perform type reconstruction to find the most gen- eral values for all these variables that make the term typecheck. (This story becomes a little more complicated in the presence of ML’s let-polymorphism; we return to this in §22.6 and §22.7.) To formalize type reconstruction, we will need a concise way of talking about the possible ways that type variables can be substituted by types, in a term and its associated context, to obtain a valid typing statement.1 22.2.1 Definition: Let Γ be a context and t a term. A solution for (Γ ,t) is a pair (σ ,T) such that σ Γ ` σt : T. � 22.2.2 Example: Let Γ = f:X, a:Y and t = f a. Then ([X, Y→Nat], Nat) ([X , Y→Z], Z) ([X, Y→Z, Z, Nat], Z) ([X , Y→Nat→Nat], Nat→Nat) ([X, Nat→Nat, Y, Nat], Nat→Nat) are all solutions for (Γ ,t). � 22.2.3 Exercise [« 3]: Find three different solutions for the term λx:X. λy:Y. λz:Z. (x z) (y z). in the empty context. � 1. There are other ways of setting up these basic definitions. One is to use a general mech- anism called existential unificands, due to Kirchner and Jouannaud (1990), instead of all the individual freshness conditions in the constraint generation rules in Figure 22-1. Another pos- sible improvement, employed by Rémy (1992a, 1992b, long version, 1998, Chapter 5), is to treat typing statements themselves as unificands; we begin with a triple (Γ ,t,T), where all three com- ponents may contain type variables, and look for substitutions σ such that σ Γ ` σ(t) : σ(T), i.e., substitutions that unify the schematic typing statement Γ ` t : T. 22.3 Constraint-Based Typing 321 22.3 Constraint-Based Typing We now present an algorithm that, given a term t and a context Γ , calculates a set of constraints—equations between type expressions (possibly involving type variables)—that must be satisfied by any solution for (Γ ,t). The intuition behind this algorithm is essentially the same as the ordinary typechecking al- gorithm; the only difference is that, instead of checking constraints, it simply records them for later consideration. For example, when presented with an application t1 t2 with Γ ` t1 : T1 and Γ ` t2 : T2, rather than checking that t1 has the form T2→T12 and returning T12 as the type of the application, it instead chooses a fresh type variable X, records the constraint T1 = T2→X, and returns X as the type of the application. 22.3.1 Definition: A constraint set C is a set of equations {Si = Ti i∈1..n}. A substi- tution σ is said to unify an equation S = T if the substitution instances σS and σT are identical. We say that σ unifies (or satisfies) C if it unifies every equation in C . � 22.3.2 Definition: The constraint typing relation Γ ` t : T |X C is defined by the rules in Figure 22-1. Informally, Γ ` t : T |X C can be read “term t has type T under assumptions Γ whenever constraints C are satisfied.” In rule T-App, we write FV(T) for the set of all type variables mentioned in T. The X subscripts are used to track the type variables introduced in each subderivation and make sure that the fresh variables created in different sub- derivations are actually distinct. On a first reading of the rules, it may be helpful to ignore these subscripts and all the premises involving them. On the next reading, observe that these annotations and premises ensure two things. First, whenever a type variable is chosen by the final rule in some derivation, it must be different from any variables chosen in subderivations. Second, whenever a rule involves two or more subderivations, the sets of vari- ables chosen by these subderivations must be disjoint. Also, note that these conditions never prevent us from building some derivation for a given term; they merely prevent us from building a derivation in which the same vari- able is used “fresh” in two different places. Since there is an infinite supply of type variable names, we can always find a way of satisfying the freshness requirements. When read from bottom to top, the constraint typing rules determine a straightforward procedure that, given Γ and t, calculates T and C (and X) such that Γ ` t : T |X C . However, unlike the ordinary typing algorithm for the simply typed lambda-calculus, this one never fails, in the sense that for every Γ and t there are always some T and C such that Γ ` t : T |X C , and moreover that T and C are uniquely determined by Γ and t. (Strictly 322 22 Type Reconstruction x:T ∈ Γ Γ ` x : T |∅ {} (CT-Var) Γ , x:T1 ` t2 : T2 |X C Γ ` λx:T1.t2 : T1→T2 |X C (CT-Abs) Γ ` t1 : T1 |X1 C1 Γ ` t2 : T2 |X2 C2 X1 ∩X2 = X1 ∩ FV(T2) = X2 ∩ FV(T1) = ∅ X ∉ X1, X2, T1, T2, C1, C2, Γ , t1, or t2 C′ = C1 ∪ C2 ∪ {T1 = T2→X} Γ ` t1 t2 : X |X1∪X2∪{X} C ′ (CT-App) Γ ` 0 : Nat |∅ {} (CT-Zero) Γ ` t1 : T |X C C′ = C ∪ {T = Nat} Γ ` succ t1 : Nat |X C ′ (CT-Succ) Γ ` t1 : T |X C C′ = C ∪ {T = Nat} Γ ` pred t1 : Nat |X C ′ (CT-Pred) Γ ` t1 : T |X C C′ = C ∪ {T = Nat} Γ ` iszero t1 : Bool |X C ′ (CT-IsZero) Γ ` true : Bool |∅ {} (CT-True) Γ ` false : Bool |∅ {} (CT-False) Γ ` t1 : T1 |X1 C1 Γ ` t2 : T2 |X2 C2 Γ ` t3 : T3 |X3 C3 X1, X2, X3 nonoverlapping C′ = C1 ∪ C2 ∪ C3 ∪ {T1 = Bool, T2 = T3} Γ ` if t1 then t2 else t3 : T2 |X1∪X2∪X3 C ′ (CT-If) Figure 22-1: Constraint typing rules speaking, the algorithm is deterministic only if we consider it “modulo the choice of fresh names.” We return to this point in Exercise 22.3.9.) To lighten the notation in the following discussion, we sometimes elide the X and write just Γ ` t : T | C . � 22.3.3 Exercise [« 3]: Construct a constraint typing derivation whose conclusion is ` λx:X. λy:Y. λz:Z. (x z) (y z) : S |X C for some S, X , and C . � The idea of the constraint typing relation is that, given a term t and a context Γ , we can check whether t is typable under Γ by first collecting the constraints C that must be satisfied in order for t to have a type, together with a result type S, sharing variables with C , that characterizes the possible types of t in terms of these variables. Then, to find solutions for t, we just look for substitutions σ that satisfy C (i.e., that make all the equations in C into identities); for each such σ , the type σS is a possible type of t. If we find that there are no substitutions that satisfy C , then we know that t cannot be instantiated in such a way as to make it typable. 22.3 Constraint-Based Typing 323 For example, the constraint set generated by the algorithm for the term t = λx:X→Y. x 0 is {Nat→Z = X→Y}, and the associated result type is (X→Y)→Z. The substitution σ = [X , Nat, Z , Bool, Y , Bool] makes the equa- tion Nat→Z = X→Y into an identity, so we know that σ((X→Y)→Z), i.e., (Nat→Bool)→Bool, is a possible type for t. This idea is captured formally by the following definition. 22.3.4 Definition: Suppose that Γ ` t : S | C . A solution for (Γ ,t,S, C) is a pair (σ ,T) such that σ satisfies C and σS = T. � The algorithmic problem of finding substitutions unifying a given con- straint set C will be taken up in the next section. First, though, we should check that our constraint typing algorithm corresponds in a suitable sense to the original, declarative typing relation. Given a context Γ and a term t, we have two different ways of characterizing the possible ways of instantiating type variables in Γ and t to produce a valid typing: 1. [declarative] as the set of all solutions for (Γ ,t) in the sense of Defini- tion 22.2.1; or 2. [algorithmic] via the constraint typing relation, by finding S and C such that Γ ` t : S | C and then taking the set of solutions for (Γ ,t,S, C). We show the equivalence of these two characterizations in two steps. First we show that every solution for (Γ ,t,S, C) is also a solution for (Γ ,t) (The- orem 22.3.5). Then we show that every solution for (Γ ,t) can be extended to a solution for (Γ ,t,S, C) (Theorem 22.3.7) by giving values for the type variables introduced by constraint generation. 22.3.5 Theorem [Soundness of constraint typing]: Suppose that Γ ` t : S | C . If (σ ,T) is a solution for (Γ ,t,S, C), then it is also a solution for (Γ ,t). � For this direction of the argument, the fresh variable sets X are secondary and can be elided. Proof: By induction on the given constraint typing derivation for Γ ` t : S | C , reasoning by cases on the last rule used. Case CT-Var: t = x x:S ∈ Γ C = {} We are given that (σ ,T) is a solution for (Γ ,t,S, C); since C is empty, this means just that σS = T. But then by T-Var we immediately obtain σ Γ ` x : T, as required. 324 22 Type Reconstruction Case CT-Abs: t = λx:T1.t2 S = T1→S2 Γ , x:T1 ` t2 : S2 | C We are given that (σ ,T) is a solution for (Γ ,t,S, C), that is, σ unifies C and T = σS = σT1 → σS2. So (σ ,σS2) is a solution for (Γ ,t2,S2, C). By the induc- tion hypothesis, (σ ,σS2) is a solution for ((Γ , x:T1), t2), i.e., σ Γ , x:σT1 ` σt2 : σS2. By T-Abs, σ Γ ` λx:σT1.σt2 : σT1→σS2 = σ(T1→S2) = T, as required. Case CT-App: t = t1 t2 S = X Γ ` t1 : S1 | C1 Γ ` t2 : S2 | C2 C = C1 ∪ C2 ∪ {S1 = S2→X} By definition, σ unifies C1 and C2 and σS1 = σ(S2→X). So (σ , σS1) and (σ , σS2) are solutions for (Γ ,t1,S1, C1) and (Γ ,t2,S2, C2), from which the induction hypothesis gives us σ Γ ` σt1 : σS1 and σ Γ ` σt2 : σS2. But since σS1 = σS2→σX, we have σ Γ ` σt1 : σS2→σX, and, by T-App, σ Γ ` σ(t1 t2) : σX = T. Other cases: Similar. � The argument for the completeness of constraint typing with respect to the ordinary typing relation is a bit more delicate, because we must deal carefully with fresh names. 22.3.6 Definition: Write σ\X for the substitution that is undefined for all the vari- ables in X and otherwise behaves like σ . � 22.3.7 Theorem [Completeness of constraint typing]: Suppose Γ ` t : S |X C . If (σ ,T) is a solution for (Γ ,t) and dom(σ) ∩ X = ∅, then there is some solution (σ ′,T) for (Γ ,t,S, C) such that σ ′\X = σ . � Proof: By induction on the given constraint typing derivation. Case CT-Var: t = x x:S ∈ Γ From the assumption that (σ ,T) is a solution for (Γ ,x), the inversion lemma for the typing relation (9.3.1) tells us that T = σS. But then (σ ,T) is also a (Γ ,x,S, {})-solution. Case CT-Abs: t = λx:T1.t2 Γ , x:T1 ` t2 : S2 |X C S = T1→S2 From the assumption that (σ ,T) is a solution for (Γ , λx:T1.t2), the in- version lemma for the typing relation yields σ Γ , x:σT1 ` σt2 : T2 and T = σT1→T2 for some T2. By the induction hypothesis, there is a solution (σ ′,T2) for ((Γ ,x:T1), t2, S2, C) such that σ ′\X agrees with σ . Now, X can- not include any of the type variables in T1. So σ ′T1 = σT1, and σ ′(S) = σ ′(T1→S2) = σT1→σ ′S2 = σT1→T2 = T. Thus, we see that (σ ′,T) is a solu- tion for (Γ , (λx:T1.t2), T1→S2, C). 22.3 Constraint-Based Typing 325 Case CT-App: t = t1 t2 Γ ` t1 : S1 |X1 C1 Γ ` t2 : S2 |X2 C2 X1 ∩X2 = ∅ X1 ∩ FV(T2) = ∅ X2 ∩ FV(T1) = ∅ X not mentioned in X1, X2, S1, S2, C1, C2 S = X X = X1 ∪X2 ∪ {X} C = C1 ∪ C2 ∪ {S1 = S2→X} From the assumption that (σ ,T) is a solution for (Γ , t1 t2), the inversion lemma for the typing relation yields σ Γ ` σt1 : T1→T and σ Γ ` σt2 : T1. By the induction hypothesis, there are solutions (σ1,T1→T) for (Γ ,t1,S1, C1) and (σ2,T1) for (Γ ,t2,S2, C2), and σ1\X1 = σ = σ2\X2. We must exhibit a substitution σ ′ such that: (1) σ ′\X agrees with σ ; (2) σ ′X = T; (3) σ ′ unifies C1 and C2; and (4) σ ′ unifies {S1 = S2→X}, i.e., σ ′S1 = σ ′S2→σ ′X. Define σ ′ as follows: σ ′ =       Y ,U if Y ∉ X and (Y, U) ∈ σ, Y1,U1 if Y1 ∈ X1 and (Y1 , U1) ∈ σ1, Y2,U2 if Y2 ∈ X2 and (Y2 , U2) ∈ σ2, X ,T       Conditions (1) and (2) are obviously satisfied. (3) is satisfied because X1 and X2 do not overlap. To check (4), first note that the side-conditions about freshness guarantee that FV(S1) ∩ (X2 ∪ {X}) = ∅, so that σ ′S1 = σ1S1. Now calculate as follows: σ ′S1 = σ1S1 = T1→T = σ2S2→T = σ ′S2→σ ′X = σ ′(S2→X). Other cases: Similar. � 22.3.8 Corollary: Suppose Γ ` t : S | C . There is some solution for (Γ ,t) iff there is some solution for (Γ ,t,S, C). � Proof: By Theorems 22.3.5 and 22.3.7. � 22.3.9 Exercise [Recommended, «««]: In a production compiler, the nondetermin- istic choice of a fresh type variable name in the rule CT-App would typically be replaced by a call to a function that generates a new type variable—different from all others that it ever generates, and from all type variables mentioned explicitly in the context or term being checked—each time it is called. Because such global “gensym” operations work by side effects on a hidden global variable, they are difficult to reason about formally. However, we can mimic their behavior in a fairly accurate and mathematically more tractable way by “threading” a sequence of unused variable names through the constraint generation rules. 326 22 Type Reconstruction Let F denote a sequence of distinct type variable names. Then, instead of writing Γ ` t : T |X C for the constraint generation relation, we write Γ `F t : T |F ′ C , where Γ , F , and t are inputs to the algorithm and T, F ′, and C are outputs. Whenever it needs a fresh type variable, the algorithm takes the front element of F and returns the rest of F as F ′. Write out the rules for this algorithm. Prove that they are equivalent, in an appropriate sense, to the original constraint generation rules. � 22.3.10 Exercise [Recommended, ««]: Implement the algorithm from Exercise 22.3.9 in ML. Use the datatype type ty = TyBool | TyArr of ty * ty | TyId of string | TyNat for types, and type constr = (ty * ty) list for constraint sets. You will also need a representation for infinite sequences of fresh variable names. There are lots of ways of doing this; here is a fairly direct one using a recursive datatype: type nextuvar = NextUVar of string * uvargenerator and uvargenerator = unit → nextuvar let uvargen = let rec f n () = NextUVar("?X_" ^ string_of_int n, f (n+1)) in f 0 That is, uvargen is a function that, when called with argument (), returns a value of the form NextUVar(x,f), where x is a fresh type variable name and f is another function of the same form. � 22.3.11 Exercise [««]: Show how to extend the constraint generation algorithm to deal with general recursive function definitions (§11.11). � 22.4 Unification To calculate solutions to constraint sets, we use the idea, due to Hindley (1969) and Milner (1978), of using unification (Robinson, 1971) to check that the set of solutions is nonempty and, if so, to find a “best” element, in the sense that all solutions can be generated straightforwardly from this one. 22.4 Unification 327 unify(C) = if C = ∅, then [ ] else let {S = T} ∪ C′ = C in if S = T then unify(C′) else if S = X and X ∉ FV(T) then unify([X , T]C′) ◦ [X, T] else if T = X and X ∉ FV(S) then unify([X , S]C′) ◦ [X, S] else if S = S1→S2 and T = T1→T2 then unify(C′ ∪ {S1 = T1, S2 = T2}) else fail Figure 22-2: Unification algorithm 22.4.1 Definition: A substitution σ is less specific (or more general) than a substi- tution σ ′, written σ v σ ′, if σ ′ = γ ◦ σ for some substitution γ. � 22.4.2 Definition: A principal unifier (or sometimes most general unifier) for a con- straint set C is a substitution σ that satisfies C and such that σ v σ ′ for every substitution σ ′ satisfying C . � 22.4.3 Exercise [«]: Write down principal unifiers (when they exist) for the follow- ing sets of constraints: {X = Nat, Y = X→X} {Nat→Nat = X→Y} {X→Y = Y→Z, Z = U→W} {Nat = Nat→Y} {Y = Nat→Y} {} (the empty set of constraints) � 22.4.4 Definition: The unification algorithm for types is defined in Figure 22-2.2 The phrase “let {S = T}∪C′ = C” in the second line should be read as “choose a constraint S=T from the set C and let C′ denote the remaining constraints from C .” � The side conditions X ∉ FV(T) in the fifth line and X ∉ FV(S) in the seventh are known as the occur check. Their effect is to prevent the algorithm from generating a solution involving a cyclic substitution like X , X→X, which 2. Note that nothing in this algorithm depends on the fact that we are unifying type expres- sions as opposed to some other sort of expressions; the same algorithm can be used to solve equality constraints between any kind of (first-order) expressions. 328 22 Type Reconstruction makes no sense if we are talking about finite type expressions. (If we expand our language to include infinite type expressions—i.e. recursive types in the sense of Chapters 20 and 21—then the occur check can be omitted.) 22.4.5 Theorem: The algorithm unify always terminates, failing when given a non- unifiable constraint set as input and otherwise returning a principal unifier. More formally: 1. unify(C) halts, either by failing or by returning a substitution, for all C ; 2. if unify(C) = σ , then σ is a unifier for C ; 3. if δ is a unifier for C , then unify(C) = σ with σ v δ. � Proof: For part (1), define the degree of a constraint set C to be the pair (m,n), where m is the number of distinct type variables in C and n is the total size of the types in C . It is easy to check that each clause of the unify algorithm either terminates immediately (with success in the first case or failure in the last) or else makes a recursive call to unify with a constraint set of lexicographically smaller degree. Part (2) is a straightforward induction on the number of recursive calls in the computation of unify(C). All the cases are trivial except for the two involving variables, which depend on the observation that, if σ unifies [X , T]D, then σ ◦ [X, T] unifies {X = T} ∪D for any constraint set D. Part (3) again proceeds by induction on the number of recursive calls in the computation of unify(C). If C is empty, then unify(C) immediately returns the trivial substitution [ ]; since δ = δ ◦ [ ], we have [ ] v δ as required. If C is non-empty, then unify(C) chooses some pair (S,T) from C and continues by cases on the shapes of S and T. Case: S = T Since δ is a unifier for C , it also unifies C′. By the induction hypothesis, unify(C) = σ with σ v δ, as required. Case: S = X and X ∉ FV(T) Since δ unifies S and T, we have δ(X) = δ(T). So, for any type U, we have δ(U) = δ([X , T]U); in particular, since δ unifies C′, it must also unify [X , T]C′. The induction hypothesis then tells us that unify([X , T]C′) = σ ′, with δ = γ ◦ σ ′ for some γ. Since unify(C) = σ ′ ◦ [X , T], showing that δ = γ ◦ (σ ′ ◦ [X , T]) will complete the argument. So consider any type variable Y. If Y ≠ X, then clearly (γ ◦ (σ ′ ◦ [X , T]))Y = (γ ◦ σ ′)Y = δY. On the other hand, (γ ◦ (σ ′ ◦ [X , T]))X = (γ ◦ σ ′)T = δX, as we saw above. Combining these observations, we see that δY = (γ ◦ (σ ′ ◦ [X , T]))Y for all variables Y, that is, δ = (γ ◦ (σ ′ ◦ [X, T])). 22.5 Principal Types 329 Case: T = X and X ∉ FV(S) Similar. Case: S = S1→S2 and T = T1→T2 Straightforward. Just note that δ is a unifier of {S1→S2 = T1→T2}∪ C ′ iff it is a unifier of C′ ∪ {S1 = T1, S2 = T2}. If none of the above cases apply to S and T, then unify(C) fails. But this can happen in only two ways: either S is Nat and T is an arrow type (or vice versa), or else S = X and X ∈ T (or vice versa). The first case obviously contradicts the assumption that C is unifiable. To see that the second does too, recall that, by assumption, δS = δT; if X occurred in T, then δT would always be strictly larger than δS. Thus, if unify(C) fails, then C is not unifiable, contradicting our assumption that δ is a unifier for C ; so this case cannot occur. � 22.4.6 Exercise [Recommended, «««]: Implement the unification algorithm. � 22.5 Principal Types We remarked above that if there is some way to instantiate the type variables in a term so that it becomes typable, then there is a most general or principal way of doing so. We now formalize this observation. 22.5.1 Definition: A principal solution for (Γ ,t,S, C) is a solution (σ ,T) such that, whenever (σ ′,T′) is also a solution for (Γ ,t,S, C), we have σ v σ ′. When (σ ,T) is a principal solution, we call T a principal type of t under Γ .3 � 22.5.2 Exercise [« 3]: Find a principal type for λx:X. λy:Y. λz:Z. (x z) (y z). � 22.5.3 Theorem [Principal types]: If (Γ ,t,S, C) has any solution, then it has a prin- cipal one. The unification algorithm in Figure 22-2 can be used to determine whether (Γ ,t,S, C) has a solution and, if so, to calculate a principal one. � Proof: By the definition of a solution for (Γ ,t,S, C) and the properties of unification. � 22.5.4 Corollary: It is decidable whether (Γ ,t) has a solution. � Proof: By Corollary 22.3.8 and Theorem 22.5.3. � 3. Principal types should not be confused with principal typings. See page 337. 330 22 Type Reconstruction 22.5.5 Exercise [Recommended, ««« 3]: Combine the constraint generation and unification algorithms from Exercises 22.3.10 and 22.4.6 to build a type- checker that calculates principal types, taking the reconbase checker as a starting point. A typical interaction with your typechecker might look like: λx:X. x; ñ : X → X

λz:ZZ. λy:YY. z (y true);

ñ : (?X0→?X1) → (Bool→?X0) → ?X1

λw:W. if true then false else w false;

ñ : (Bool→Bool) → Bool

Type variables with names like ?X0 are automatically generated. �

22.5.6 Exercise [«««]: What difficulties arise in extending the definitions above

(22.3.2, etc.) to deal with records? How might they be addressed? �

The idea of principal types can be used to build a type reconstruction algo-

rithm that works more incrementally than the one we have developed here.

Instead of generating all the constraints first and then trying to solve them,

we can interleave generation and solving, so that the type reconstruction al-

gorithm actually returns a principal type at each step. The fact that the types

are always principal ensures that the algorithm never needs to re-analyze a

subterm: it makes only the minimum commitments needed to achieve typa-

bility at each step. One major advantage of such an algorithm is that it can

pinpoint errors in the user’s program much more precisely.

22.5.7 Exercise [««« 3]: Modify your solution to Exercise 22.5.5 so that it per-

forms unification incrementally and returns principal types. �

22.6 Implicit Type Annotations

Languages supporting type reconstruction typically allow programmers to

completely omit type annotations on lambda-abstractions. One way to achieve

this (as we remarked in §22.2) is simply to make the parser fill in omitted an-

notations with freshly generated type variables. A better alternative is to add

un-annotated abstractions to the syntax of terms and a corresponding rule to

the constraint typing relation.

22.7 Let-Polymorphism 331

X ∉ X Γ , x:X ` t1 : T |X C

Γ ` λx.t1 : X→T |X∪{X} C
(CT-AbsInf)

This account of un-annotated abstractions is a bit more direct than regarding

them as syntactic sugar. It is also more expressive, in a small but useful way:

if we make several copies of an un-annotated abstraction, the CT-AbsInf rule

will allow us to choose a different variable as the argument type of each copy.

By contrast, if we regard a bare abstraction as being annotated with an invis-

ible type variable, then making copies will yield several expressions sharing

the same argument type. This difference is important for the discussion of

let-polymorphism in the following section.

22.7 Let-Polymorphism

The term polymorphism refers to a range of language mechanisms that allow

a single part of a program to be used with different types in different contexts

(§23.2 discusses several varieties of polymorphism in more detail). The type

reconstruction algorithm shown above can be generalized to provide a simple

form of polymorphism known as let-polymorphism (also ML-style or Damas-

Milner polymorphism). This feature was introduced in the original dialect

of ML (Milner, 1978) and has been incorporated in a number of successful

language designs, where it forms the basis of powerful generic libraries of

commonly used structures (lists, arrays, trees, hash tables, streams, user-

interface widgets, etc.).

The motivation for let-polymorphism arises from examples like the follow-

ing. Suppose we define and use a simple function double, which applies its

first argument twice in succession to its second:

let double = λf:Nat→Nat. λa:Nat. f(f(a)) in

double (λx:Nat. succ (succ x)) 2;

Because we want to apply double to a function of type Nat→Nat, we choose

type annotations that give it type (Nat→Nat)→(Nat→Nat). We can alterna-

tively define double so that it can be used to double a boolean function:

let double = λf:Bool→Bool. λa:Bool. f(f(a)) in

double (λx:Bool. x) false;

What we cannot do is use the same double function with both booleans and

numbers: if we need both in the same program, we must define two versions

that are identical except for type annotations.

let doubleNat = λf:Nat→Nat. λa:Nat. f(f(a)) in

let doubleBool = λf:Bool→Bool. λa:Bool. f(f(a)) in

332 22 Type Reconstruction

let a = doubleNat (λx:Nat. succ (succ x)) 1 in

let b = doubleBool (λx:Bool. x) false in …

Even annotating the abstractions in double with a type variable

let double = λf:X→X. λa:X. f(f(a)) in …

does not help. For example, if we write

let double = λf:X→X. λa:X. f(f(a)) in

let a = double (λx:Nat. succ (succ x)) 1 in

let b = double (λx:Bool. x) false in …

then the use of double in the definition of a generates the constraint X→X =

Nat→Nat, while the use of double in the definition of b generates the con-

straint X→X = Bool→Bool. These constraints place unsatisfiable demands on

X, making the whole program untypable.

What went wrong here? The variable X plays two distinct roles in the exam-

ple. First, it captures the constraint that the first argument to double in the

calculation of a must be a function whose domain and range types are the

same as the type (Nat) of the other argument to double. Second, it captures

the constraint that the arguments to double in the calculation of b must be

similarly related. Unfortunately, because the same variable X is used in both

cases, we also end up with the spurious constraint that the second arguments

to the two uses of double must have the same type.

What we’d like is to break this last connection—i.e., to associate a different

variable X with each use of double. Fortunately, this is easily accomplished.

The first step is to change the ordinary typing rule for let so that, instead of

calculating a type for the right-hand side t1 and then using this as the type

of the bound variable x while calculating a type for the body t2,

Γ ` t1 : T1 Γ , x:T1 ` t2 : T2

Γ ` let x=t1 in t2 : T2
(T-Let)

it instead substitutes t1 for x in the body, and then typechecks this expanded

expression:

Γ ` [x, t1]t2 : T2

Γ ` let x=t1 in t2 : T2
(T-LetPoly)

We write a constraint-typing rule for let in a similar way:

Γ ` [x, t1]t2 : T2 |X C

Γ ` let x=t1 in t2 : T2 |X C
(CT-LetPoly)

In essence, what we’ve done is to change the typing rules for let so that they

perform a step of evaluation

let x=v1 in t2 -→ [x, v1]t2 (E-LetV)

22.7 Let-Polymorphism 333

before calculating types.

The second step is to rewrite the definition of double using the implicitly

annotated lambda-abstractions from §22.6.

let double = λf. λa. f(f(a)) in

let a = double (λx:Nat. succ (succ x)) 1 in

let b = double (λx:Bool. x) false in …

The combination of the constraint typing rules for let (CT-LetPoly) and the

implicitly annotated lambda-abstraction (CT-AbsInf) gives us exactly what

we need: CT-LetPoly makes two copies of the definition of double, and

Ct-AbsInf assigns each of the abstractions a different type variable. The or-

dinary process of constraint solving does the rest.

However, this scheme has some flaws that need to be addressed before we

can use it in practice. One obvious one is that, if we don’t happen to actually

use the let-bound variable in the body of the let, then the definition will

never actually be typechecked. For example, a program like

let x = in 5

will pass the typechecker. This can be repaired by adding a premise to the

typing rule

Γ ` [x, t1]t2 : T2 Γ ` t1 : T1

Γ ` let x=t1 in t2 : T2
(T-LetPoly)

and a corresponding premise to CT-LetPoly, ensuring that t1 is well typed.

A related problem is that, if the body of the let contains many occur-

rences of the let-bound variable, then the whole right-hand side of the let-

definition will be checked once per occurrence, whether or not it contains any

implicitly annotated lambda-abstractions. Since the right-hand side itself can

contain let-bindings, this typing rule can cause the typechecker to perform

an amount of work that is exponential in the size of the original term!

To avoid this re-typechecking, practical implementations of languages with

let-polymorphism actually use a more clever (though formally equivalent)

re-formulation of the typing rules. In outline, the typechecking of a term

let x=t1 in t2 in a context Γ proceeds as follows:

1. We use the constraint typing rules to calculate a type S1 and a set C1 of

associated constraints for the right-hand side t1.

2. We use unification to find a most general solution σ to the constraints C1

and apply σ to S1 (and Γ ) to obtain t1’s principal type T1.

3. We generalize any variables remaining in T1. If X1. . .Xn are the remaining

variables, we write ∀X1…Xn.T1 for the principal type scheme of t1.

334 22 Type Reconstruction

One caveat is here that we need to be careful not to generalize variables

T1 that are also mentioned in Γ , since these correspond to real constraints

between t1 and its environment. For example, in

λf:X→X. λx:X. let g=f in g(x);

we should not generalize the variable X in the type X→X of g, since doing

so would allow us to type wrong programs like this one:

(λf:X→X. λx:X. let g=f in g(0))

(λx:Bool. if x then true else false)

true;

4. We extend the context to record the type scheme ∀X1…Xn.T1 for the

bound variable x, and start typechecking the body t2. In general, the con-

text now associates each free variable with a type scheme, not just a type.

5. Each time we encounter an occurrence of x in t2, we look up its type

scheme ∀X1…Xn.T1. We now generate fresh type variables Y1…Yn and

use them to instantiate the type scheme, yielding [X1 , Y1, . . . , Xn ,

Yn]T1, which we use as the type of x.
4

This algorithm is much more efficient than the simplistic approach of sub-

stituting away let expressions before typechecking. Indeed, decades of ex-

perience have shown that in practice it appears “essentially linear” in the size

of the input program. It therefore came as a significant surprise when Kfoury,

Tiuryn, and Urzyczyn (1990) and independently Mairson (1990) showed that

its worst-case complexity is still exponential! The example they constructed

involves using deeply nested sequences of lets in the right-hand sides of

other lets—rather than in their bodies, where nesting of lets is common—

to build expressions whose types grow exponentially larger than the expres-

sions themselves. For example, the following OCaml program, due to Mairson

(1990), is well typed but takes a very long time to typecheck.

let f0 = fun x → (x,x) in

let f1 = fun y → f0(f0 y) in

let f2 = fun y → f1(f1 y) in

let f3 = fun y → f2(f2 y) in

let f4 = fun y → f3(f3 y) in

let f5 = fun y → f4(f4 y) in

f5 (fun z → z)

4. The difference between a lambda-abstraction that is explicitly annotated with a type vari-

able and an un-annotated abstraction for which the constraint generation algorithm creates

a variable becomes moot once we introduce generalization and instantiation. Either way, the

right-hand side of a let is assigned a type involving a variable, which is generalized before

being added to the context and replaced by a fresh variable every time it is instantiated.

22.7 Let-Polymorphism 335

To see why, try entering f0, f1, etc., one at a time, into the OCaml top-level.

See Kfoury, Tiuryn, and Urzyczyn (1994) for further discussion.

A final point worth mentioning is that, in designing full-blown program-

ming languages with let-polymorphism, we need to be a bit careful of the in-

teraction of polymorphism and side-effecting features such as mutable stor-

age cells. A simple example illustrates the danger:

let r = ref (λx. x) in

(r:=(λx:Nat. succ x); (!r)true);

Using the algorithm sketched above, we calculate Ref(X→X) as the principal

type of the right-hand side of the let; since X appears nowhere else, this

type can be generalized to ∀X.Ref(X→X), and we assign this type scheme to

r when we add it to the context. When typechecking the assignment in the

second line, we instantiate this type to Ref(Nat→Nat). When typechecking

the third line, we instantiate it to Ref(Bool→Bool). But this is unsound,

since when the term is evaluated it will end up applying succ to true.

The problem here is that the typing rules have gotten out of sync with

the evaluation rules. The typing rules introduced in this section tell us that,

when we see a let expression, we should immediately substitute the right-

hand side into the body. But the evaluation rules tell us that we may perform

this substitution only after the right-hand side has been reduced to a value.

The typing rules see two uses of the ref constructor, and analyze them under

different assumptions, but at run time only one ref is actually allocated.

We can correct this mismatch in two ways—by adjusting evaluation or typ-

ing. In the former case, the evaluation rule for let would become5

let x=t1 in t2 -→ [x, t1]t2 (E-Let)

Under this strategy, the first step in evaluating our dangerous example from

above would replace r by its definition, yielding

(ref (λx. x)) := (λx:Nat. succ x) in

(!(ref (λx. x))) true;

which is perfectly safe! The first line creates a reference cell initially contain-

ing the identity function, and stores (λx:Nat. succ x) into it. The second

creates another reference containing the identity, extracts its contents, and

applies it to true. However, this calculation also demonstrates that changing

the evaluation rule to fit the typing rule gives us a language with a rather

5. Strictly speaking, we should annotate this rule with a store, as we did in Chapter 13, since

we are talking about a language with references:

let x=t1 in t2 | µ -→ [x, t1]t2 | µ (E-Let)

336 22 Type Reconstruction

strange semantics that no longer matches standard intuitions about call-by-

value evaluation order. (Imperative languages with non-CBV evaluation strate-

gies are not unheard-of [Augustsson, 1984], but they have never become pop-

ular because of the difficulty of understanding and controlling the ordering

of side effects at run time.)

It is better to change the typing rule to match the evaluation rule. Fortu-

nately, this is easy: we just impose the restriction (often called the value re-

striction) that a let-binding can be treated polymorphically—i.e., its free type

variables can be generalized—only if its right-hand side is a syntactic value.

This means that, in the dangerous example, the type assigned to r when we

add it to the context will be X→X, not ∀X.X→X. The constraints imposed by

the second line will force X to be Nat, and this will cause the typechecking of

the third line to fail, since Nat cannot be unified with Bool.

The value restriction solves our problem with type safety, at some cost

in expressiveness: we can no longer write programs in which the right-hand

sides of let expressions can both perform some interesting computation

and be assigned a polymorphic type scheme. What is surprising is that this

restriction makes hardly any difference in practice. Wright (1995) settled this

point by analyzing a huge corpus of code written in an ML dialect—the 1990

definition of Standard ML (Milner, Tofte, and Harper, 1990)—that provided

a more flexible let-typing rule based on weak type variables and observing

that all but a tiny handful of right-hand sides were syntactic values anyway.

This observation more or less closed the argument, and all major languages

with ML-style let-polymorphism now adopt the value restriction.

22.7.1 Exercise [««« 3]: Implement the algorithm sketched in this section. �

22.8 Notes

Notions of principal types for the lambda-calculus go back at least to the

work of Curry in the 1950s (Curry and Feys, 1958). An algorithm for calcu-

lating principal types based on Curry’s ideas was given by Hindley (1969);

similar algorithms were discovered independently by Morris (1968) and Mil-

ner (1978). In the world of propositional logic, the ideas go back still fur-

ther, perhaps to Tarski in the 1920s and certainly to the Meredith cousins in

the 1950s (Lemmon, Meredith, Meredith, Prior, and Thomas, 1957); their first

implementation on a computer was by David Meredith in 1957. Additional

historical remarks on principal types can be found in Hindley (1997).

Unification (Robinson, 1971) is fundamental to many areas of computer

science. Thorough introductions can be found, for example, in Baader and

Nipkow (1998), Baader and Siekmann (1994), and Lassez and Plotkin (1991).

22.8 Notes 337

ML-style let-polymorphism was first described by Milner (1978). A num-

ber of type reconstruction algorithms have been proposed, notably the clas-

sic Algorithm W (Damas and Milner) of Damas and Milner (1982; also see

Lee and Yi, 1998). The main difference between Algorithm W and the pre-

sentation in this chapter is that the former is specialized for “pure type

reconstruction”—assigning principal types to completely untyped lambda-

terms—while we have mixed type checking and type reconstruction, permit-

ting terms to include explicit type annotations that may, but need not, contain

variables. This makes our technical presentation a bit more involved (espe-

cially the proof of completeness, Theorem 22.3.7, where we must be careful

to keep the programmer’s type variables separate from the ones introduced

by the constraint generation rules), but it meshes better with the style of the

other chapters.

A classic paper by Cardelli (1987) lays out a number of implementation

issues. Other expositions of type reconstruction algorithms can be found

in Appel (1998), Aho et al. (1986), and Reade (1989). A particularly elegant

presentation of the core system called mini-ML (Clement, Despeyroux, De-

speyroux, and Kahn, 1986) often forms the basis for theoretical discussions.

Tiuryn (1990) surveys a range of type reconstruction problems.

Principal types should not be confused with the similar notion of prin-

cipal typings. The difference is that, when we calculate principal types, the

context Γ and term t are considered as inputs to the algorithm, while the

principal type T is the output. An algorithm for calculating principal typings

takes just t as input and yields both Γ and T as outputs—i.e., it calculates

the minimal assumptions about the types of the free variables in t. Principal

typings are useful in supporting separate compilation and “smartest recompi-

lation,” performing incremental type inference, and pinpointing type errors.

Unfortunately, many languages, in particular ML, have principal types but not

principal typings. See Jim (1996).

ML-style polymorphism, with its striking combination of power and sim-

plicity, hits a “sweet spot” in the language design space; mixing it with other

sophisticated typing features has often proved quite delicate. The biggest

success story in this arena is the elegant account of type reconstruction for

record types proposed by Wand (1987) and further developed by Wand (1988,

1989b), Remy (1989, 1990; 1992a, 1992b, 1998), and many others. The idea

is to introduce a new kind of variable, called a row variable, that ranges not

over types but over entire “rows” of field labels and associated types. A simple

form of equational unification is used solve constraint sets involving row vari-

ables. See Exercise 22.5.6. Garrigue (1994) and others have developed related

methods for variant types. These techniques have been extended to general

notions of type classes (Kaes, 1988; Wadler and Blott, 1989), constraint types

338 22 Type Reconstruction

(Odersky, Sulzmann, and Wehr, 1999), and qualified types (Jones, 1994b,a),

which form the basis of Haskell’s system of type classes (Hall et al., 1996; Hu-

dak et al., 1992; Thompson, 1999); similar ideas appear in Mercury (Somogyi,

Henderson, and Conway, 1996) and Clean (Plasmeijer, 1998).

Type reconstruction for the more powerful form of impredicative poly-

morphism discussed in Chapter 23 was shown to be undecidable by Wells

(1994). Indeed, several forms of partial type reconstruction for this system

also turn out to be undecidable. §23.6 and §23.8 give more information on

these results and on methods for combining ML-style type reconstruction

with stronger forms of polymorphism such as rank-2 polymorphism.

For the combination of subtyping with ML-style type reconstruction, some

promising initial results have been reported (Aiken and Wimmers, 1993; Eifrig,

Smith, and Trifonov, 1995; Jagannathan and Wright, 1995; Trifonov and Smith,

1996; Odersky, Sulzmann, and Wehr, 1999; Flanagan and Felleisen, 1997; Pot-

tier, 1997), but practical checkers have yet to see widespread use.

Extending ML-style type reconstruction to handle recursive types (Chap-

ter 20) has been shown not to pose significant difficulties (Huet, 1975, 1976).

The only significant difference from the algorithms presented in this chapter

appears in the definition of unification, where we omit the occur check (which

ordinarily ensures that the substitution returned by the unification algorithm

is acyclic). Having done this, to ensure termination we also need to modify the

representation used by the unification algorithm so that it maintains sharing,

e.g., using by destructive operations on (potentially cyclic) pointer structures.

Such representations are common in high-performance implementations.

The mixture of type reconstruction with recursively defined terms, on the

other hand, raises one tricky problem, known as polymorphic recursion. A

simple (and unproblematic) typing rule for recursive function definitions in

ML specifies that a recursive function can be used within the body of its def-

inition only monomorphically (i.e., all recursive calls must have identically

typed arguments and results), while occurrences in the rest of the program

may be used polymorphically (with arguments and results of different types).

Mycroft (1984) and Meertens (1983) proposed a polymorphic typing rule for

recursive definitions that allows recursive calls to a recursive function from

its own body to be instantiated with different types. This extension, often

called the Milner-Mycroft Calculus, was shown to have an undecidable recon-

struction problem by Henglein (1993) and independently by Kfoury, Tiuryn,

and Urzyczyn (1993a); both of these proofs depend on the undecidability

of the (unrestricted) semi-unification problem, shown by Kfoury, Tiuryn, and

Urzyczyn (1993b).

23 Universal Types

In the previous chapter, we studied the simple form of let-polymorphism

found in ML. In this chapter, we consider a more general form of polymor-

phism in the setting of a powerful calculus known as System F .

23.1 Motivation

As we remarked in §22.7, we can write an infinite number of “doubling” func-

tions in the simply typed lambda-calculus…

doubleNat = λf:Nat→Nat. λx:Nat. f (f x);

doubleRcd = λf:{l:Bool}→{l:Bool}. λx:{l:Bool}. f (f x);

doubleFun = λf:(Nat→Nat)→(Nat→Nat). λx:Nat→Nat. f (f x);

Each of these functions is applicable to a different type of argument, but all

share precisely the same behavior (indeed, they share precisely the same pro-

gram text, aside from the typing annotations). If we want apply the doubling

operation to different types of arguments within the same program, we will

need to write out separate definitions of doubleT for each T. This kind of

cut-and-paste programming violates a basic dictum of software engineering:

Abstraction principle: Each significant piece of functionality in a

program should be implemented in just one place in the source code.

Where similar functions are carried out by distinct pieces of code, it

is generally beneficial to combine them into one by abstracting out the

varying parts.

The system studied in most of this chapter is pure System F (Figure 23-1); the examples in

§23.4 use various extensions with previously studied features. The associated OCaml im-

plementation is fullpoly. (The examples involving pairs and lists require the fullomega

checker.)

340 23 Universal Types

Here, the varying parts are the types! What we need, then, are facilities for

abstracting out a type from a term and later instantiating this abstract term

with concrete type annotations.

23.2 Varieties of Polymorphism

Type systems that allow a single piece of code to be used with multiple types

are collectively known as polymorphic systems (poly = many, morph = form).

Several varieties of polymorphism can be found in modern languages (this

classification comes from Strachey, 1967, and Cardelli and Wegner, 1985).

Parametric polymorphism, the topic of this chapter, allows a single piece of

code to be typed “generically,” using variables in place of actual types, and

then instantiated with particular types as needed. Parametric definitions

are uniform: all of their instances behave the same.

The most powerful form of parametric polymorphism is the impredica-

tive or first-class polymorphism developed in this chapter. More common

in practice is the form known as ML-style or let-polymorphism, which re-

stricts polymorphism to top-level let-bindings, disallowing functions that

take polymorphic values as arguments, and obtains in return a convenient

and natural form of automatic type reconstruction (Chapter 22). First-class

parametric polymorphism is also becoming popular in programming lan-

guages, and forms the technical foundation for the powerful module sys-

tems of languages like ML (see Harper and Stone, 2000).

Ad-hoc polymorphism, by contrast, allows a polymorphic value to exhibit

different behaviors when “viewed” at different types. The most common

example of ad-hoc polymorphism is overloading, which associates a single

function symbol with many implementations; the compiler (or the run-

time system, depending on whether overloading resolution is static or dy-

namic) chooses an appropriate implementation for each application of the

function, based on the types of the arguments.

A generalization of function overloading forms the basis for multi-method

dispatch in languages such as CLOS (Bobrow et al., 1988; Kiczales et al.,

1991) and Cecil (Chambers, 1992; Chambers and Leavens, 1994). This mech-

anism has been formalized in the λ-& calculus of Castagna, Ghelli, and

Longo (1995; cf. Castagna, 1997).

A more powerful form of ad-hoc polymorphism known as intensional poly-

morphism (Harper and Morrisett, 1995; Crary, Weirich, and Morrisett, 1998)

permits restricted computation over types at run time. Intensional poly-

morphism is an enabling technology for a variety of advanced implemen-

23.3 System F 341

tation techniques for polymorphic languages, including tag-free garbage

collection, “unboxed” function arguments, polymorphic marshaling, and

space-efficient “flattened” data structures.

Yet more powerful forms of ad-hoc polymorphism can be built from a

typecase primitive, which permits arbitrary pattern-matching on type in-

formation at run time (Abadi, Cardelli, Pierce, and Rémy, 1995; Abadi,

Cardelli, Pierce, and Plotkin, 1991b; Henglein, 1994; Leroy and Mauny,

1991; Thatte, 1990). Language features such as Java’s instanceof test

can be viewed as restricted forms of typecase.

The subtype polymorphism of Chapter 15 gives a single term many types

using the rule of subsumption, allowing us to selectively “forget” informa-

tion about the term’s behavior.

These categories are not exclusive: different forms of polymorphism can be

mixed in the same language. For example, Standard ML offers both parametric

polymorphism and simple overloading of built-in arithmetic operations, but

not subtyping, while Java includes subtyping, overloading, and simple ad-hoc

polymorphism (instanceof), but not (at the time of this writing) parametric

polymorphism. There are several proposals for adding parametric polymor-

phism to Java; the best known of these is GJ (Bracha, Odersky, Stoutamire,

and Wadler, 1998).

The unqualified term “polymorphism” causes a certain amount of confu-

sion between programming language communities. Among functional pro-

gramers (i.e., those who use or design languages like ML, Haskell, etc.), it al-

most always refers to parametric polymorphism. Among object-oriented pro-

grammers, on the other hand, it almost always means subtype polymorphism,

while the term genericity (or generics) is used for parametric polymorphism.

23.3 System F

The system we will be studying in this chapter, commonly called System F ,

was first discovered by Jean-Yves Girard (1972), in the context of proof theory

in logic. A little later, a type system with essentially the same power was de-

veloped, independently, by a computer scientist, John Reynolds (1974), who

called it the polymorphic lambda-calculus. This system has been used ex-

tensively as a research vehicle for foundational work on polymorphism and

as the basis for numerous programming language designs. It is also some-

times called the second-order lambda-calculus, because it corresponds, via

the Curry-Howard correspondence, to second-order intuitionistic logic, which

allows quantification not only over individuals [terms], but also over predi-

cates [types].

342 23 Universal Types

The definition of System F is a straightforward extension of λ→, the simply

typed lambda-calculus. In λ→, lambda-abstraction is used to abstract terms

out of terms, and application is used to supply values for the abstracted

parts. Since we want here a mechanism for abstracting types out of terms and

filling them in later, we introduce a new form of abstraction, written λX.t,

whose parameter is a type, and a new form of application, t [T], in which the

argument is a type expression. We call our new abstractions type abstractions

and the new application construct type application or instantiation.

When, during evaluation, a type abstraction meets a type application, the

pair forms a redex, just as in λ→. We add a reduction rule

(λX.t12) [T2] -→ [X, T2]t12 (E-TappTabs)

analogous to the ordinary reduction rule for abstractions and applications.

(λx:T11.t12) v2 -→ [x, v2]t12 (E-AppAbs)

For example, when the polymorphic identity function

id = λX. λx:X. x;

is applied to Nat by writing id [Nat], the result is [X , Nat](λx:X.x), i.e.,

λx:Nat.x, the identity function on natural numbers.

Finally, we need to specify the type of a polymorphic abstraction. We use

types like Nat→Nat for classifying ordinary functions like λx:Nat.x; we now

need a different form of “arrow type” whose domain is a type, for classifying

polymorphic functions like id. Notice that, for each argument T to which it

is applied, id yields a function of type T→T; that is, the type of the result

of id depends on the actual type that we pass it as argument. To capture

this dependency, we write the type of id as ∀X.X→X. The typing rules for

polymorphic abstraction and application are analogous to the rules for term-

level abstraction and application.

Γ , X ` t2 : T2

Γ ` λX.t2 : ∀X.T2
(T-TAbs)

Γ ` t1 : ∀X.T12

Γ ` t1 [T2] : [X, T2]T12
(T-TApp)

Note that we include the type variable X in the context used by the subderiva-

tion for t. We continue the convention (5.3.4) that the names of (term or type)

variables should be chosen so as to be different from all the names already

bound by Γ , and that lambda-bound type variables may be renamed at will

in order to satisfy this condition. (In some presentations of System F, this

freshness condition is given as an explicit side condition on the T-TAbs rule,

instead of being built into the rules about how contexts are constructed, as

we are doing here.) For the moment, the only role of type variables in contexts

23.3 System F 343

→∀ Based on λ→ (9-1)

Syntax

t ::= terms:

x variable

λx:T.t abstraction

t t application

λX.t type abstraction

t [T] type application

v ::= values:

λx:T.t abstraction value

λX.t type abstraction value

T ::= types:

X type variable

T→T type of functions

∀X.T universal type

Γ ::= contexts:

∅ empty context

Γ , x:T term variable binding

Γ , X type variable binding

Evaluation t -→ t′

t1 -→ t
′
1

t1 t2 -→ t
′
1
t2

(E-App1)

t2 -→ t
′
2

v1 t2 -→ v1 t
′
2

(E-App2)

(λx:T11.t12) v2 -→ [x, v2]t12 (E-AppAbs)

t1 -→ t
′
1

t1 [T2] -→ t
′
1
[T2]

(E-TApp)

(λX.t12) [T2] -→ [X, T2]t12 (E-TappTabs)

Typing Γ ` t : T

x:T ∈ Γ

Γ ` x : T
(T-Var)

Γ , x:T1 ` t2 : T2

Γ ` λx:T1.t2 : T1→T2
(T-Abs)

Γ ` t1 : T11→T12 Γ ` t2 : T11

Γ ` t1 t2 : T12
(T-App)

Γ , X ` t2 : T2

Γ ` λX.t2 : ∀X.T2
(T-TAbs)

Γ ` t1 : ∀X.T12

Γ ` t1 [T2] : [X, T2]T12
(T-TApp)

Figure 23-1: Polymorphic lambda-calculus (System F)

is to keep track of scopes and make sure that the same type variable is not

added twice to a context. In later chapters, we will annotate type variables

with information of various kinds, such as bounds (Chapter 26) and kinds

(Chapter 29).

Figure 23-1 shows the complete definition of the polymorphic lambda-

calculus, with differences from λ→ highlighted. As usual, this summary de-

fines just the pure calculus, omitting other type constructors such as records,

344 23 Universal Types

base types such as Nat and Bool, and term-language extensions such as let

and fix. These extra constructs can be added straightforwardly to the pure

system, and we will use them freely in the examples that follow.

23.4 Examples

We now develop several examples of programming with polymorphism. To

warm up, we start with a few small but increasingly tricky examples, showing

some of the expressive power of System F. We then review the basic ideas

of “ordinary” polymorphic programming with lists, trees, etc. The last two

subsections introduce typed versions of the Church encodings of simple al-

gebraic datatypes like booleans, numbers, and lists that we saw in Chapter 5

for the untyped lambda-calculus. Although these encodings are of small prac-

tical importance—it is easier to compile good code for these important fea-

tures if they are built into high-level programming languages as primitives—

they make excellent exercises for understanding both the intricacies and the

power of System F. In Chapter 24, we will see some additional applications

of polymorphism in the domain of modular programming and abstract data

types.

Warm-ups

We have seen already how type abstraction and application can be used to

define a single polymorphic identity function

id = λX. λx:X. x;

ñ id : ∀X. X → X

and instantiate it to yield any concrete identity function that may be required:

id [Nat];

ñ : Nat → Nat

id [Nat] 0;

ñ 0 : Nat

A more useful example is the polymorphic doubling function:

double = λX. λf:X→X. λa:X. f (f a);

ñ double : ∀X. (X→X) → X → X

23.4 Examples 345

The abstraction on the type X allows us to obtain doubling functions for spe-

cific types by instantiating double with different type arguments:

doubleNat = double [Nat];

ñ doubleNat : (Nat→Nat) → Nat → Nat

doubleNatArrowNat = double [Nat→Nat];

ñ doubleNatArrowNat : ((Nat→Nat)→Nat→Nat) →

(Nat→Nat) → Nat → Nat

Once instantiated with a type argument, double can be further applied to an

actual function and argument of appropriate types:

double [Nat] (λx:Nat. succ(succ(x))) 3;

ñ 7 : Nat

Here is a slightly trickier example: polymorphic self-application. Recall that,

in the simply typed lambda-calculus, there is no way to type the untyped term

λx. x x (Exercise 9.3.2). In System F, on the other hand, this term becomes

typable if we give x a polymorphic type and instantiate it appropriately:

selfApp = λx:∀X.X→X. x [∀X.X→X] x;

ñ selfApp : (∀X. X→X) → (∀X. X → X)

As a (slightly) more useful example of self application, we can apply the poly-

morphic double function to itself, yielding a polymorphic quadrupling func-

tion:

quadruple = λX. double [X→X] (double [X]);

ñ quadruple : ∀X. (X→X) → X → X

23.4.1 Exercise [« 3]: Using the typing rules in Figure 23-1, convince yourself that

the terms above have the types given. �

Polymorphic Lists

Most real-world programming with polymorphism is much more pedestrian

than the tricky examples above. As an example of straightforward polymor-

phic programming, suppose our programming language is equipped with a

type constructor List and term constructors for the usual list manipulation

primitives, with the following types.

346 23 Universal Types

ñ nil : ∀X. List X

cons : ∀X. X → List X → List X

isnil : ∀X. List X → Bool

head : ∀X. List X → X

tail : ∀X. List X → List X

When we first introduced lists in §11.12, we used “custom” inference rules to

allow the operations to be applied to lists with elements of any type. Here,

we can give the operations polymorphic types expressing exactly the same

constraints—that is, lists no longer need to be “baked into” the core lan-

guage, but can simply be considered as a library providing several constants

with particular polymorphic types. The same holds for the Ref type and the

primitive operations on reference cells in Chapter 13, and many other com-

mon data and control structures.

We can use these primitives to define our own polymorphic operations on

lists. For example, here is a polymorphic map function that takes a function

from X to Y and a list of Xs and returns a list of Ys.

map = λX. λY.

λf: X→Y.

(fix (λm: (List X) → (List Y).

λl: List X.

if isnil [X] l

then nil [Y]

else cons [Y] (f (head [X] l))

(m (tail [X] l))));
ñ map : ∀X. ∀Y. (X→Y) → List X → List Y

l = cons [Nat] 4 (cons [Nat] 3 (cons [Nat] 2 (nil [Nat])));

ñ l : List Nat

head [Nat] (map [Nat] [Nat] (λx:Nat. succ x) l);

ñ 5 : Nat

23.4.2 Exercise [« 3]: Convince yourself that map really has the type shown. �

23.4.3 Exercise [Recommended, ««]: Using map as a model, write a polymorphic

list-reversing function:

reverse : ∀X. List X → List X.

This exercise is best done on-line. Use the fullomega checker and copy the

contents of the file test.f from the fullomega directory to the top of your

own input file. (The file contains definitions of the List constructor and as-

sociated operations that require the powerful abstraction facilities of System

Fω, discussed in Chapter 29. You do not need to understand exactly how they

work to proceed with the present exercise.) �

23.4 Examples 347

23.4.4 Exercise [«« 3]: Write a simple polymorphic sorting function

sort : ∀X. (X→X→Bool) → (List X) → List X

where the first argument is a comparison function for elements of type X. �

Church Encodings

We saw in §5.2 that a variety of primitive data values such as booleans,

numbers, and lists can be encoded as functions in the pure untyped lambda-

calculus. In this section, we show how these Church encodings can also be

carried out in System F. Readers may want to refer to §5.2 to refresh their

intuitions about Church encodings.

These encodings are interesting for two reasons. First, they give our under-

standing of type abstraction and application a good workout. Second, they

demonstrate that System F, like the pure untyped lambda-calculus, is compu-

tationally a very rich language, in the sense that the pure system can express

a large range of data and control structures. This means that, if we later de-

sign a full-scale programming language with System F as its core, we can add

these features as primitives (for efficiency, and so that we can equip them

with more convenient concrete syntax) without disturbing the fundamental

properties of the core language. This will not be true of all interesting high-

level language features, of course. For example, adding references to System

F, as we did for λ→in Chapter 13, represents a real change in the fundamental

computational nature of the system.

Let us begin with the Church booleans. Recall that, in the untyped lambda-

calculus, we represented the boolean constants true and false by lambda-

terms tru and fls defined like this:

tru = λt. λf. t;

fls = λt. λf. f;

Each of these terms takes two arguments and returns one of them. If we want

to assign a common type to tru and fls, we had better assume that the two

arguments have the same type (since the caller will not know whether it is

interacting with tru or fls), but this type may be arbitrary (since tru and

fls do not need to do anything with their arguments except return one of

them). This leads us to the following type for tru and fls.

CBool = ∀X.X→X→X;

The System-F terms tru and fls are obtained by adding appropriate type

annotations to the untyped versions above.

348 23 Universal Types

tru = λX. λt:X. λf:X. t;

ñ tru : CBool

fls = λX. λt:X. λf:X. f;

ñ fls : CBool

We can write common boolean operations like not by constructing a new

boolean that uses an existing one to decide which of its arguments to return:

not = λb:CBool. λX. λt:X. λf:X. b [X] f t;

ñ not : CBool → CBool

23.4.5 Exercise [Recommended, «]: Write a term and that takes two arguments of

type CBool and computes their conjunction. �

We can play a similar game with numbers. The Church numerals introduced

in §5.2 encode each natural number n as a function that take two arguments

s and z and applies s to z, n times:

c0 = λs. λz. z;

c1 = λs. λz. s z;

c2 = λs. λz. s (s z);

c3 = λs. λz. s (s (s z));

Clearly, the z argument should have the same type as the domain of s, and

the result returned by s should again have the same type. This leads us to the

following type for Church numerals in System F:

CNat = ∀X. (X→X) → X → X;

The elements of this type are obtained by adding appropriate annotations to

the untyped Church numerals:

c0 = λX. λs:X→X. λz:X. z;

ñ c0 : CNat

c1 = λX. λs:X→X. λz:X. s z;

ñ c1 : CNat

c2 = λX. λs:X→X. λz:X. s (s z);

ñ c2 : CNat

A typed successor function on Church numerals can be defined as follows.

23.4 Examples 349

csucc = λn:CNat. λX. λs:X→X. λz:X. s (n [X] s z);

ñ csucc : CNat → CNat

That is, csucc n returns an element of CNat that, given s and z, applies s to

z, n times (by applying n to s and z), and then once more. Other arithmetic

operations can be defined similarly. For example, addition can be defined

either in terms of successor,

cplus = λm:CNat. λn:CNat. m [CNat] csucc n;

ñ cplus : CNat → CNat → CNat

or more directly:

cplus = λm:CNat. λn:CNat. λX. λs:X→X. λz:X. m [X] s (n [X] s z);

ñ cplus : CNat → CNat → CNat

If our language also includes primitive numbers (Figure 8-2), then we can

convert from Church numerals to ordinary ones using the following function:

cnat2nat = λm:CNat. m [Nat] (λx:Nat. succ(x)) 0;

ñ cnat2nat : CNat → Nat

This allows us to verify that our operations on Church numerals actually

compute the desired arithmetic functions:

cnat2nat (cplus (csucc c0) (csucc (csucc c0)));

ñ 3 : Nat

23.4.6 Exercise [Recommended, ««]: Write a function iszero that will return tru

when applied to the Church numeral c0 and fls otherwise. �

23.4.7 Exercise [«« 3]: Verify that the terms

ctimes = λm:CNat. λn:CNat. λX. λs:X→X. n [X] (m [X] s);

ñ ctimes : CNat → CNat → CNat

cexp = λm:CNat. λn:CNat. λX. n [X→X] (m [X]);

ñ cexp : CNat → CNat → CNat

have the indicated types. Give an informal argument that they implement the

arithmetic multiplication and exponentiation operators. �

23.4.8 Exercise [Recommended, ««]: Show that the type

350 23 Universal Types

PairNat = ∀X. (CNat→CNat→X) → X;

can be used to represent pairs of numbers, by writing functions

pairNat : CNat→CNat→PairNat;

fstNat : PairNat→CNat;

sndNat : PairNat→CNat;

for constructing elements of this type from pairs of numbers and for access-

ing their first and second components. �

23.4.9 Exercise [Recommended, «««]: Use the functions defined in Exercise 23.4.8

to write a function pred that computes the predecessor of a Church numeral

(returning 0 if its input is 0). Hint: the key idea is developed in the example

in §5.2. Define a function f : PairNat→PairNat that maps the pair (i, j)

into (i + 1, i)—that is, it throws away the second component of its argument,

copies the first component to the second, and increments the first. Then n

applications of f to the starting pair (0,0) yields the pair (n,n − 1), from

which we extract the predecessor of n by projecting the second component. �

23.4.10 Exercise [«««]: There is another way of computing the predecessor function

on Church numerals. Let k stand for the untyped lambda-term λx. λy. x and

i for λx. x. The untyped lambda-term

vpred = λn. λs. λz. n (λp. λq. q (p s)) (k z) i

(from Barendregt, 1992, who attributes it to J. Velmans) computes the pre-

decessor of an untyped Church numeral. Show that this term can be typed

in System F by adding type abstractions and applications as necessary and

annotating the bound variables in the untyped term with appropriate types.

For extra credit, explain why it works! �

Encoding Lists

As a final example, let us extend the Church encodings of numbers to lists.

This is a nice demonstration of the expressive power of pure System F, since it

shows that all of the programming examples in the subsection above on poly-

morphic list manipulation can actually be expressed in the pure language.

(For convenience, we do use the fix construct for defining general recursive

functions, but essentially the same constructions can be carried out without

it. See Exercises 23.4.11 and 23.4.12.)

We saw in Exercise 5.2.8 that lists can be encoded in the untyped lambda-

calculus in a fashion quite similar to the encoding of natural numbers. In

effect, a number in unary notation is like a list of dummy elements. Gen-

eralizing this idea to elements of any type, we arrive at a Church encoding

23.4 Examples 351

for lists, where a list with elements x, y, and z is represented as a function

that, given any function f and starting value v, calculates f x (f y (f z v)).

In OCaml terminology, a list is represented as its own fold_right function.

The type List X of lists with elements of type X is defined as follows:

List X = ∀R. (X→R→R) → R → R;

The nil value for this representation of lists easy to write.1

nil = λX. (λR. λc:X→R→R. λn:R. n) as List X;

ñ nil : ∀X. List X

The cons and isnil operations are also easy:

cons = λX. λhd:X. λtl:List X.

(λR. λc:X→R→R. λn:R. c hd (tl [R] c n)) as List X;

ñ cons : ∀X. X → List X → List X

isnil = λX. λl:List X. l [Bool] (λhd:X. λtl:Bool. false) true;

ñ isnil : ∀X. List X → Bool

For the head operation, we need to work a little harder. The first difficulty

is what to do about head of the empty list. We can address this by recalling

that, if we have a general fixed point operator in the language, we can use it

to construct an expression of any type. In fact, using type abstraction, we can

go further and write a single, uniform function that, given a type X, yields a

function from Unit to X that diverges when applied to unit.

diverge = λX. λ_:Unit. fix (λx:X. x);

ñ diverge : ∀X. Unit → X

Now we can use diverge [X] unit as the “result” of head [X] nil.

head = λX. λl:List X. l [X] (λhd:X. λtl:X. hd) (diverge [X] unit);

ñ head : ∀X. List X → X

Unfortunately, this definition is not yet quite what we want: it will always

diverge, even when applied to non-empty lists. To get the right behavior, we

need to reorganize it a little so that diverge[X] is not actually passed its

Unit argument when it is supplied as an argument to l. This is accomplished

by removing the unit argument and changing the type of the first argument

to l correspondingly:

1. The as annotation here helps the typechecker print the type of nil in a readable form.

As we saw in §11.4, all the typecheckers used in this book perform a simple abbreviation-

collapsing step before printing types, but the collapsing function is not smart enough to deal

automatically with “parametric abbreviations” like List.

352 23 Universal Types

head =

λX. λl:List X.

(l [Unit→X] (λhd:X. λtl:Unit→X. λ_:Unit. hd) (diverge [X]))

unit;

ñ head : ∀X. List X → X

That is, l is applied to a function of type X→(Unit→X)→(Unit→X) and a

base value of type Unit→X, and it constructs a function of type Unit→X. In

the case where l represents the empty list, this result will be diverge[X];

but in the case where l represents a non-empty list, the result will be a func-

tion that takes unit and returns the head element of l. The result from l

is applied to unit at the end to get the actual head element (or, if we are

unlucky, diverge), so that head has the type we expect.

For the tail function, we use the abbreviation Pair X Y (generalizing the

PairNat type from Exercise 23.4.8) for the Church encoding of pairs with

first component of type X and second component of type Y:

Pair X Y = ∀R. (X→Y→R) → R;

The operations on pairs are simple generalizations of the operations on the

type PairNat above:

ñ pair : ∀X. ∀Y. X → Y → Pair X Y

fst : ∀X. ∀Y. Pair X Y → X

snd : ∀X. ∀Y. Pair X Y → Y

Now the tail function can be written like this:

tail =

λX. λl: List X.

(fst [List X] [List X] (

l [Pair (List X) (List X)]

(λhd: X. λtl: Pair (List X) (List X).

pair [List X] [List X]

(snd [List X] [List X] tl)

(cons [X] hd (snd [List X] [List X] tl)))

(pair [List X] [List X] (nil [X]) (nil [X]))));

ñ tail : ∀X. List X → List X

23.4.11 Exercise [««]: Strictly speaking, the examples in this subsection have not

been expressed in pure System F, since we used the fix operator to con-

struct a value to be “returned” when head is applied to an empty list. Write

an alternative version of head that takes an extra parameter to be returned

(instead of diverging) when the list is empty. �

23.5 Basic Properties 353

23.4.12 Exercise [Recommended, «««]: In pure System F (without fix), write a func-

tion insert of type

∀X. (X→X→Bool) → List X → X → List X

that takes a comparison function, a sorted list, and a new element, and inserts

the element into the list at the appropriate point (i.e., after all the elements

smaller than it). Next, use insert to build a sorting function for lists in pure

System F. �

23.5 Basic Properties

The fundamental properties of System F are very similar to those of the sim-

ply typed lambda-calculus. In particular, the proofs of type preservation and

progress are straightforward extensions of the ones we saw in Chapter 9.

23.5.1 Theorem [Preservation]: If Γ ` t : T and t -→ t′, then Γ ` t′ : T. �

Proof: Exercise [Recommended, «««]. �

23.5.2 Theorem [Progress]: If t is a closed, well-typed term, then either t is a value

or else there is some t′ with t -→ t′. �

Proof: Exercise [Recommended, «««]. �

System F also shares with λ→ the property of normalization—the fact that

the evaluation of every well-typed program terminates.2 Unlike the type

safety theorems above, normalization is quite difficult to prove (indeed, it is

somewhat astonishing that it holds at all, considering that we can code things

like sorting functions in the pure language, as we did in Exercise 23.4.12, with-

out resorting to fix). This proof, based on a generalization of the method

presented in Chapter 12, was a major achievement of Girard’s doctoral thesis

(1972; also see Girard, Lafont, and Taylor, 1989). Since then, his proof tech-

nique has been analyzed and reworked by many others; see Gallier (1990).

23.5.3 Theorem [Normalization]: Well-typed System F terms are normalizing. �

2. Indeed, presentations of System F with more permissive operational semantics based on

full beta-reduction have the strong normalization property: every reduction path starting from

a well-typed term is guaranteed to terminate.

354 23 Universal Types

23.6 Erasure, Typability, and Type Reconstruction

As we did for λ→ in §9.5, we can define a type erasure function mapping

System F terms to untyped lambda-terms by stripping out all their type an-

notations (including all type abstractions and applications):

erase(x) = x

erase(λx:T1. t2) = λx. erase(t2)

erase(t1 t2) = erase(t1) erase(t2)

erase(λX. t2) = erase(t2)

erase(t1 [T2]) = erase(t1)

A term M in the untyped lambda-calculus is said to be typable in System F if

there is some well-typed term t such that erase(t) = m. The type reconstruc-

tion problem then asks, given an untyped term m, whether we can find some

well-typed term that erases to m.

Type reconstruction for System F was one of the longest-standing prob-

lems in the programming languages literature, remaining open from the early

1970s until it was finally settled (negatively) by Wells in the early 1990s.

23.6.1 Theorem [Wells, 1994]: It is undecidable whether, given a closed term m of

the untyped lambda-calculus, there is some well-typed term t in System F

such that erase(t) = m. �

Not only full type reconstruction but also various forms of partial type

reconstruction are known to be undecidable for System F. For example, con-

sider the following “partial erasure” function, which leaves intact all typing

annotations except the arguments to type applications:

erasep(x) = x

erasep(λx:T1. t2) = λx:T1. erasep(t2)

erasep(t1 t2) = erasep(t1) erasep(t2)

erasep(λX. t2) = λX. erasep(t2)

erasep(t1 [T2]) = erasep(t1) []

Note that type applications are still marked (with empty square brackets) in

the erased terms; we can see where they must occur, but not what type must

be supplied.

23.6.2 Theorem [Boehm 1985, 1989]: It is undecidable whether, given a closed term

s in which type applications are marked but the arguments are omitted, there

is some well-typed System F term t such that erasep(t) = s. �

Boehm showed that this form of type reconstruction was just as hard as

higher-order unification, hence undecidable. Interestingly, this negative re-

sult led directly to a useful partial type reconstruction technique (Pfenning,

23.6 Erasure, Typability, and Type Reconstruction 355

1988, 1993a) based on Huet’s earlier work on efficient semi-algorithms for

higher-order unification (Huet, 1975). Later improvements in this line of de-

velopment have included using a more refined algorithm for higher-order

constraint solving (Dowek, Hardin, Kirchner, and Pfenning, 1996), eliminat-

ing the troublesome possibilities of nontermination or generation of non-

unique solutions. Experience with related algorithms in languages such as

LEAP (Pfenning and Lee, 1991), Elf (Pfenning, 1989), and FX (O’Toole and Gif-

ford, 1989) has shown them to be quite well behaved in practice.

A different approach to partial type reconstruction was sparked by Perry’s

observation that first-class existential types (see Chapter 24) can be inte-

grated with ML’s datatype mechanism (Perry, 1990); the idea was further

developed by Läufer and Odersky (Läufer, 1992; Läufer and Odersky, 1994).

In essence, datatype constructors and destructors can be regarded as ex-

plicit type annotations, marking where values must be injected into and pro-

jected from disjoint union types, where recursive types must be folded and

unfolded, and (when existentials are added) where packing and unpacking

must occur. This idea was extended to include first-class (impredicative) uni-

versal quantifiers by Rémy (1994). A more recent proposal by Odersky and

Läufer (1996), further developed by Garrigue and Rémy (1997), conservatively

extends ML-style type reconstruction by allowing programmers to explicitly

annotate function arguments with types, which may (unlike the annotations

that can be inferred automatically) contain embedded universal quantifiers,

thus partly bridging the gap between ML and more powerful impredicative

systems. This family of approaches to type reconstruction has the advantage

of relative simplicity and clean integration with the polymorphism of ML.

A pragmatic approach to partial type reconstruction for systems involving

both subtyping and impredicative polymorphism, called local type inference

(or local type reconstruction), was proposed by Pierce and Turner (1998; also

see Pierce and Turner, 1997; Hosoya and Pierce, 1999). Local type inference

has appeared in several recent language designs, including GJ (Bracha, Oder-

sky, Stoutamire, and Wadler, 1998) and Funnel (Odersky and Zenger, 2001),

the latter introducing a more powerful form called colored local type inference

(Odersky, Zenger, and Zenger, 2001).

A simpler but less predictable greedy type inference algorithm was pro-

posed by Cardelli (1993); similar algorithms have also been used in proof-

checkers for dependent type theories, such as NuPrl (Howe, 1988) and Lego

(Pollack, 1990). The idea here is that any type annotation may be omitted

by the programmer: a fresh unification variable X will be generated for each

one by the parser. During typechecking, the subtype-checking algorithm may

be asked to check whether some type S is a subtype T, where both S and T

may contain unification variables. Subtype-checking proceeds as usual until a

356 23 Universal Types

subgoal of the form X <: T or T <: X is encountered, at which point X is instan- tiated to T, thus satisfying the immediate constraint in the simplest possible way. However, setting X to T may not be the best possible choice, and this may cause later subtype-checks for types involving X to fail when a different choice would have allowed them to succeed; but, again, practical experience with this algorithm in Cardelli’s implementation and in an early version of the Pict language (Pierce and Turner, 2000) shows that the algorithm’s greedy choice is correct in nearly all cases. However, when it goes wrong, the greedy algorithm’s behavior can be quite puzzling to the programmer, yielding mys- terious errors far from the point where a suboptimal instantiation is made. 23.6.3 Exercise [««««]: The normalization property implies that the untyped term omega = (λx. x x) (λy. y y) cannot be typed in System F, since reduction of omega never reaches a normal form. However, it is possible to give a more direct, “combinatorial” proof of this fact, using just the rules defining the typing relation. 1. Let us call a System F term exposed if it is a variable, an abstraction λx:T.t, or an application t s (i.e., if it is not a type abstraction λX.t or type application t [S]). Show that if t is well typed (in some context) and erase(t) = m, then there is some exposed term s such that erase(s) = m and s is well typed (possibly in a different context). 2. Write λX.t as shorthand for a nested sequence of type abstractions of the form λX1. . .λXn.t. Similarly, write t [A] for a nested sequence of type applications ((t [A1]) . . .[An−1]) [An] and ∀X.T for a nested sequence of polymorphic types∀X1. . .∀Xn.T. Note that these sequences are allowed to be empty. For example, if X is the empty sequence of type variables, then ∀X.T is just T. Show that if erase(t) = m and Γ ` t : T, then there exists some s of the form λX. (u [A]), for some sequence of type variables X, some sequence of types A, and some exposed term u, with erase(s) = m and Γ ` s : T. 3. Show that if t is an exposed term of type T (under Γ ) and erase(t) = m n, then t has the form s u for some terms s and u such that erase(s) = m and erase(u) = n, with Γ ` s : U→T and Γ ` u : U. 4. Suppose x:T ∈ Γ . Show that if Γ ` u : U and erase(u) = x x, then either (a) T = ∀X.Xi , where Xi ∈ X, or else (b) T = ∀X1X2.T1→T2, where [X1X2 , A]T1 = [X1 , B](∀Z.T1→T2) for some sequences of types A and B with |A| = |X1X2| and |B| = |X1|. 23.7 Erasure and Evaluation Order 357 5. Show that if erase(s) = λx.m and Γ ` s : S, then S has the form∀X.S1→S2, for some X, S1, and S2. 6. Define the leftmost leaf of a type T as follows: leftmost-leaf(X) = X leftmost-leaf(S→T) = leftmost-leaf(S) leftmost-leaf(∀X.S) = leftmost-leaf(S). Show that if [X1X2 , A](∀Y.T1) = [X1 , B](∀Z.(∀Y.T1)→T2), then it must be the case that leftmost-leaf(T1) = Xi for some Xi ∈ X1X2. 7. Show that omega is not typable in System F. � 23.7 Erasure and Evaluation Order The operational semantics given to System F in Figure 23-1 is a type-passing semantics: when a polymorphic function meets a type argument, the type is actually substituted into the body of the function. The ML implementation of System F in Chapter 25 does exactly this. In a more realistic interpreter or compiler for a programming language based on System F, this manipulation of types at run time could impose a significant cost. Moreover, it is easy to see that type annotations play no sig- nificant role at run time, in the sense that no run-time decisions are made on the basis of types: we can take a well-typed program, rewrite its type annota- tions in an arbitrary way, and obtain a program that behaves just the same. For these reasons, many polymorphic languages instead adopt a type-erasure semantics, where, after the typechecking phase, all the types are erased and the resulting untyped terms are interpreted or compiled to machine code.3 However, in a full-blown programming language, which may include side- effecting features such as mutable reference cells or exceptions, the type- erasure function needs to be defined a little more delicately than the full era- sure function in §23.6. For example, if we extend System F with an exception- raising primitive error (§14.1), then the term let f = (λX.error) in 0; 3. In some languages, the presence of features like casts (§15.5) forces a type-passing imple- mentation. High-performance implementations of these languages typically attempt to main- tain only a vestigial form of type information at run time, e.g., passing types only to polymor- phic functions where they may actually be used. 358 23 Universal Types evaluates to 0 because λX.error is a syntactic value and the error in its body is never evaluated, while its erasure let f = error in 0; raises an exception when evaluated.4 What this shows is that type abstrac- tions do play a significant semantic role, since they stop evaluation under a call-by-value evaluation strategy and hence can postpone or prevent the evaluation of side-effecting primitives. We can repair this discrepancy by introducing a new form of erasure ap- propriate for call-by-value evaluation, in which we erase a type abstraction to a term-abstraction erasev(x) = x erasev(λx:T1. t2) = λx. erasev(t2) erasev(t1 t2) = erasev(t1) erasev(t2) erasev(λX. t2) = λ_. erasev(t2) erasev(t1 [T2]) = erasev(t1) dummyv where dummyv is some arbitrary untyped value, such as unit.5 The appropri- ateness of this new erasure function is expressed by the observation that it “commutes” with untyped evaluation, in the sense that erasure and evalua- tion can be performed in either order: 23.7.2 Theorem: If erasev(t) = u, then either (1) both t and u are normal forms according to their respective evaluation relations, or (2) t -→ t′ and u -→ u′, with erasev(t ′) = u′. � 23.8 Fragments of System F The elegance and power of System F have earned it a central role in theoret- ical studies of polymorphism. For language design, however, the loss of type 4. This is related to the problem we saw with the unsound combination of references and ML-style let-polymorphism in §22.7. The generalization of the let-body in that example corre- sponds to the explicit type abstraction here. 23.7.1 Exercise [««]: Translate the unsound example on page 335 into System F extended with ref- erences (Figure 13-1). � 5. In contrast, the value restriction that we imposed in order to recover soundness of ML-style type reconstruction in the presence of side effects in §22.7 does erase type-abstractions— generalizing a type variable is essentially the opposite of erasing a type abstraction—but en- sures soundness by permitting such generalizations only when the inferred type abstraction would occur immediately adjacent to a term abstraction or other syntactic value-constructor, since these also stop evaluation. 23.9 Parametricity 359 reconstruction is sometimes considered to be too heavy a price to pay for a feature whose full power is seldom used. This has led to various propos- als for restricted fragments of System F with more tractable reconstruction problems. The most popular of these is the let-polymorphism of ML (§22.7), which is sometimes called prenex polymorphism because it can be viewed as a frag- ment of System F in which type variables range only over quantifier-free types (monotypes) and in which quantified types (polytypes, or type schemes) are not allowed to appear on the left-hand sides of arrows. The special role of let in ML makes the correspondence slightly tricky to state precisely; see Jim (1995) for details. Another well-studied restriction of System F is rank-2 polymorphism, in- troduced by Leivant (1983) and further investigated by many others (see Jim, 1995, 1996). A type is said to be of rank 2 if no path from its root to a ∀ quantifier passes to the left of 2 or more arrows, when the type is drawn as a tree. For example, (∀X.X→X)→Nat is of rank 2, as are Nat→Nat and Nat→(∀X.X→X)→Nat→Nat, but ((∀X.X→X)→Nat)→Nat is not. In the rank- 2 system, all types are restricted to be of rank 2. This system is slightly more powerful than the prenex (ML) fragment, in the sense that it can assign types to more untyped lambda-terms. Kfoury and Tiuryn (1990) proved that the complexity of type reconstruc- tion for the rank-2 fragment of System F is identical to that of ML (i.e., DExptime-complete). Kfoury and Wells (1999) gave the first correct type re- construction algorithm for the rank 2 system and showed that type recon- struction for ranks 3 and higher of System F is undecidable. The rank-2 restriction can be applied to other powerful type construc- tors besides quantifiers. For example, intersection types (see §15.7) can be restricted to rank 2 by excluding types in which an intersection appears to the left of 2 or more arrows (Kfoury, Mairson, Turbak, and Wells, 1999). The rank-2 fragments of System F and of the first-order intersection type system are closely related. Indeed, Jim (1995) showed that they can type exactly the same untyped terms. 23.9 Parametricity Recall from §23.4 how we defined the type CBool of Church booleans CBool = ∀X.X→X→X; and the constants tru and fls: tru = λX. λt:X. λf:X. t; 360 23 Universal Types ñ tru : CBool fls = λX. λt:X. λf:X. f; ñ fls : CBool Given the type CBool, we can actually write the definitions of tru and fls rather mechanically, simply by looking at the structure of the type. Since CBool begins with a ∀, any value of type CBool must be a type abstraction, so tru and fls must both begin with a λX. Then, since the body of CBool is an arrow type X→X→X, every value of this type must take two arguments of type X—i.e., the bodies of tru and fls must each begin λt:X.λf:X. Finally, since the result type of CBool is X, any value of type CBool must return an element of type X. But since X is a parameter, the only values of this type that we can possibly return are the bound variables t and f—we have no other way of obtaining or constructing values of this type ourselves. In other words, tru and fls are essentially the only inhabitants of the type CBool. Strictly speaking, CBool contains some other terms like (λb:CBool.b) tru, but it is intuitively clear that every one of them must behave like either tru or fls. This observation is a simple consequence of a powerful principle known as parametricity, which formalizes the uniform behavior of polymorphic pro- grams. Parametricity was introduced by Reynolds (1974, 1983) and has been further explored, along with related notions, by Reynolds (1984, Reynolds and Plotkin, 1993), Bainbridge et al. (1990), Ma (1992), Mitchell (1986), Mitchell and Meyer (1985), Hasegawa (1991), Pitts (1987, 1989, 2000), Abadi, Cardelli, Curien, and Plotkin (Abadi, Cardelli, and Curien, 1993; Plotkin and Abadi, 1993; Plotkin, Abadi, and Cardelli, 1994), Wadler (1989, 2001), and others. See Wadler (1989) for an expository introduction. 23.10 Impredicativity The polymorphism of System F is often called impredicative. In general, a definition (of a set, a type, etc.) is called “impredicative” if it involves a quan- tifier whose domain includes the very thing being defined. For example, in System F, the type variable X in the type T = ∀X.X→X ranges over all types, including T itself (so that, for example, we can instantiate a term of type T at type T, yielding a function from T to T). The polymorphism found in ML, on the other hand, is often called predicative (or stratified), because the range of type variables is restricted to monotypes, which do not contain quantifiers. The terms “predicative” and “impredicative” originate in logic. Quine (1987) offers a lucid summary of their history: 23.11 Notes 361 In exchanges with Henri Poincaré . . . Russell attributed [Russell’s] paradox tentatively to what he called a vicious-circle fallacy. The “fallacy” consisted in specifying a class by a membership condition that makes reference di- rectly or indirectly to a range of classes one of which is the very class that is being specified. For instance the membership condition behind Russell’s Paradox is non-self-membership: x not a member of x. The paradox comes of letting the x of the membership condition be, among other things, the very class that is being defined by the membership condition. Russell and Poincaré came to call such a membership condition impredicative, and dis- qualified it as a means of specifying a class. The paradoxes of set theory, Russell’s and others, were thus dismantled. . . Speaking of terminology, whence “predicative” and “impredicative”? Our tattered platitude about classes and membership conditions was, in Rus- sell’s phrase, that every predicate determines a class; and then he accom- modates the tattering of the platitude by withdrawing the title of predi- cate from such membership conditions as were no longer to be seen as determining classes. “Predicative” thus did not connote the hierarchical approach in particular, or the metaphor of progressive construction; that was just Russell and Poincaré’s particular proposal of what membership conditions to accept as class-productive, or “predicative.” But the tail soon came to wag the dog. Today predicative set theory is constructive set the- ory, and impredicative definition is strictly as explained in the foregoing paragraph, regardless of what membership conditions one may choose to regard as determining classes. 23.11 Notes Further reading on System F can be found in Reynolds’s introductory article (1990) and his Theories of Programming Languages (1998b). 24 Existential Types Having examined the role of universal quantifiers in type systems (Chap- ter 23), it is natural to wonder whether existential quantifiers might also be useful in programming. Indeed they are, offering an elegant foundation for data abstraction and information hiding. 24.1 Motivation Existential types are fundamentally no more complicated than universal types (in fact, we will see in §24.3 that existentials can straightforwardly be encoded in terms of universals). However, the introduction and elimination forms for existential types are syntactically a bit heavier than the simple type abstrac- tion and application associated with universals, and some people find them slightly puzzling initially. The following intuitions may be helpful in getting through this phase. The universal types in Chapter 23 can be viewed in two different ways. A logical intuition is that an element of the type ∀X.T is a value that has type [X , S]T for all choices of S. This intuition corresponds to a type-erasure view of behavior: for example, the polymorphic identity function λX.λx:X.x erases to the untyped identity function λx.x, which maps an argument from any type S to a result of the same type. By contrast, a more operational intu- ition is that an element of∀X.T is a function mapping a type S to a specialized term with type [X , S]T. This intuition corresponds to our definition of Sys- tem F in Chapter 23, where the reduction of a type application is considered an actual step of computation. Similarly, there are two different ways of looking at an existential type, written {∃X,T}. The logical intuition is that an element of {∃X,T} is a value The system studied in most of this chapter is System F (Figure 23-1) with existentials (24-1). The examples also use records (11-7) and numbers (8-2). The associated OCaml implementa- tion is fullpoly. 364 24 Existential Types of type [X , S]T, for some type S. The operational intuition, on the other hand, is that an element of {∃X,T} is a pair, written {*S,t}, of a type S and a term t of type [X, S]T. We will emphasize the operational view of existential types in this chap- ter, because it provides a closer analogy between existentials and the mod- ules and abstract data types found in programming languages. Our concrete syntax for existential types reflects this analogy: we write {∃X,T}—the curly braces emphasizing that an existential value is a form of tuple—instead of the more standard notation ∃X.T. To understand existential types, we need to know two things: how to build (or introduce, in the jargon of §9.4) elements that inhabit them, and how to use (or eliminate) these values in computations. An existentially typed value is introduced by pairing a type with a term, written {*S,t}.1 A useful concrete intuition is to think of a value {*S,t} of type {∃X,T} as a simple form of package or module with one (hidden) type component and one term component.2 The type S is often called the hidden representation type, or sometimes (to emphasize a connection with logic, cf. §9.4) the witness type of the package. For example, the package p = {*Nat, {a=5, f=λx:Nat. succ(x)}} has the existential type {∃X, {a:X, f:X→X}}. The type component of p is Nat, and the value component is a record containing a field a of type X and a field f of type X→X, for some X (namely Nat). The same package p also has the type {∃X, {a:X, f:X→Nat}}, since its right-hand component is a record with fields a and f of type X and X→Nat, for some X (namely Nat). This example shows that, in general, the typechecker cannot make an automatic decision about which existential type a given pack- age belongs to: the programmer must specify which one is intended. The simplest way to do this is just to add an annotation to every package that ex- plicitly gives its intended type. So the full introduction form for existentials will look like this, p = {*Nat, {a=5, f=λx:Nat. succ(x)}} as {∃X, {a:X, f:X→X}}; ñ p : {∃X, {a:X,f:X→X}} 1. We mark the type component of the pair with a * to avoid confusion with ordinary term- tuples (§11.7). Another common notation for existential introduction is pack X=S with t. 2. Obviously, one could imagine generalizing these modules to many type and/or term com- ponents, but let’s stick with just one of each to keep the notation tractable. The effect of multiple type components can be achieved by nesting single-type existentials, while the effect of multiple term components can be achieved by using a tuple or record as the right-hand component: {*S1, *S2, t1, t2} def = {*S1, {*S2, {t1, t2}}} 24.1 Motivation 365 or (the same package with a different type): p1 = {*Nat, {a=5, f=λx:Nat. succ(x)}} as {∃X, {a:X, f:X→Nat}}; ñ p1 : {∃X, {a:X,f:X→Nat}} The type annotation introduced by as is similar to the ascription construct introduced in §11.4, which allows any term to be annotated with its intended type. We are essentially incorporating a single ascription as part of the con- crete syntax of the package construct. The typing rule for existential intro- duction is as follows: Γ ` t2 : [X, U]T2 Γ ` {*U,t2} as {∃X,T2} : {∃X,T2} (T-Pack) One thing to notice about this rule is that packages with different hidden representation types can inhabit the same existential type. For example: p2 = {*Nat, 0} as {∃X,X}; ñ p2 : {∃X, X} p3 = {*Bool, true} as {∃X,X}; ñ p3 : {∃X, X} Or, more usefully: p4 = {*Nat, {a=0, f=λx:Nat. succ(x)}} as {∃X, {a:X, f:X→Nat}}; ñ p4 : {∃X, {a:X,f:X→Nat}} p5 = {*Bool, {a=true, f=λx:Bool. 0}} as {∃X, {a:X, f:X→Nat}}; ñ p5 : {∃X, {a:X,f:X→Nat}} 24.1.1 Exercise [«]: Here are three more variations on the same theme: p6 = {*Nat, {a=0, f=λx:Nat. succ(x)}} as {∃X, {a:X, f:X→X}}; ñ p6 : {∃X, {a:X,f:X→X}} p7 = {*Nat, {a=0, f=λx:Nat. succ(x)}} as {∃X, {a:X, f:Nat→X}}; ñ p7 : {∃X, {a:X,f:Nat→X}} p8 = {*Nat, {a=0, f=λx:Nat. succ(x)}} as {∃X, {a:Nat, f:Nat→Nat}}; ñ p8 : {∃X, {a:Nat,f:Nat→Nat}} In what ways are these less useful than p4 and p5? � 366 24 Existential Types → ∀ ∃ Extends System F (23-1) New syntactic forms t ::= ... terms: {*T,t} as T packing let {X,x}=t in t unpacking v ::= ... values: {*T,v} as T package value T ::= ... types: {∃X,T} existential type New evaluation rules t -→ t′ let {X,x}=({*T11,v12} as T1) in t2 -→ [X, T11][x, v12]t2 (E-UnpackPack) t12 -→ t ′ 12 {*T11,t12} as T1 -→ {*T11,t ′ 12 } as T1 (E-Pack) t1 -→ t ′ 1 let {X,x}=t1 in t2 -→ let {X,x}=t′ 1 in t2 (E-Unpack) New typing rules Γ ` t : T Γ ` t2 : [X, U]T2 Γ ` {*U,t2} as {∃X,T2} : {∃X,T2} (T-Pack) Γ ` t1 : {∃X,T12} Γ , X, x:T12 ` t2 : T2 Γ ` let {X,x}=t1 in t2 : T2 (T-Unpack) Figure 24-1: Existential types The analogy with modules also offers a helpful intuition for the existen- tial elimination construct. If an existential package corresponds to a module, then package elimination is like an open or import directive: it allows the components of the module to be used in some other part of the program, but holds abstract the identity of the module’s type component. This can be achieved with a kind of pattern-matching binding: Γ ` t1 : {∃X,T12} Γ , X, x:T12 ` t2 : T2 Γ ` let {X,x}=t1 in t2 : T2 (T-Unpack) That is, if t1 is an expression that yields an existential package, then we can bind its type and term components to the pattern variables X and x and use them in computing t2. (Another common concrete syntax for existential elimination is open t1 as {X,x} in t2.) For example, take the package p4, of type {∃X, {a:X, f:X→Nat}}, defined above. The elimination expression let {X,x}=p4 in (x.f x.a); ñ 1 : Nat 24.1 Motivation 367 opens p4 and uses the fields of its body (x.f and x.a) to compute a numeric result. The body of the elimination form can also involve the type variable X: let {X,x}=p4 in (λy:X. x.f y) x.a; ñ 1 : Nat The fact that the package’s representation type is held abstract during the typechecking of the body means that the only operations allowed on x are those warranted by its “abstract type” {a:X,f:X→Nat}. In particular, we are not allowed to use x.a concretely as a number: let {X,x}=p4 in succ(x.a); ñ Error: argument of succ is not a number This restriction makes good sense, since we saw above that a package with the same existential type as p4 might use either Nat or Bool (or anything else) as its representation type. There is another, more subtle, way in which typechecking of the existen- tial elimination construct may fail. In the rule T-Unpack, the type variable X appears in the context in which t2’s type is calculated, but does not appear in the context of the rule’s conclusion. This means that the result type T2 cannot contain X free, since any free occurrences of X will be out of scope in the conclusion. let {X,x}=p in x.a; ñ Error: Scoping error! This point is discussed in more detail in §25.5. The computation rule for existentials is straightforward: let {X,x}=({*T11,v12} as T1) in t2 -→ [X, T11][x , v12]t2 (E-UnpackPack) If the first subexpression of the let has already been reduced to a concrete package, then we may substitute the components of this package for the vari- ables X and x in the body t2. In terms of the analogy with modules, this rule can be viewed as a linking step, in which symbolic names (X and x) referring to the components of a separately compiled module are replaced by the actual contents of the module. Since the type variable X is substituted away by this rule, the resulting program actually has concrete access to the package’s internals. This is just another example of a phenomenon we have seen several times: expressions can become “more typed” as computation proceeds—in particular an ill-typed expression can reduce to a well-typed one. The rules defining the extension of System F with existential types are sum- marized in Figure 24-1. 368 24 Existential Types 24.2 Data Abstraction with Existentials The introductory chapter (§1.2) argued that the uses of type systems go far beyond their role in detecting small-scale programming errors like 2+true: they also offer crucial support for programming in the large. In particular, types can be used to enforce not only the abstractions built into the language, but also programmer-defined abstractions—i.e., not only protecting the ma- chine from the program, but protecting parts of the program from each other.3 This section considers two different styles of abstraction—classical abstract data types, and objects—using existential types as a common frame- work for discussion. Unlike the object encodings that we have already encountered in Chap- ter 18, all the examples in this section are purely functional programs. This is purely an expository choice: mechanisms for modularity and abstraction are almost completely orthogonal to the statefulness or statelessness of the abstractions being defined. (Exercises 24.2.2 and 24.2.4 illustrate this point by developing stateful versions of some of the purely functional examples in the text.) The reasons for preferring purely functional examples here are that (1) this choice implies that our examples live in a simpler and more economical formal framework, and (2) working with purely functional pro- grams sometimes makes the typing problems more interesting (and their solutions correspondingly more revealing). The reason for this is that, in im- perative programming, mutable variables provide a “side-channel” allowing direct communication between distant parts of a program. In purely func- tional programs, all information that passes between different parts of the program must go via the arguments and results of functions, where it is “vis- ible” to the type system. This is particularly true in the case of objects, and it will force us to postpone treatment of some important features (subtyping and inheritance) until Chapter 32, where we will have some more powerful type-theoretic machinery at our disposal. Abstract Data Types A conventional abstract data type (or ADT ) consists of (1) a type name A, (2) a concrete representation type T, (3) implementations of some operations for creating, querying, and manipulating values of type T, and (4) an abstraction boundary enclosing the representation and operations. Inside this bound- 3. For the sake of fairness, we should note that types are not the only way of protecting programmer-defined abstractions. In untyped languages, similar effects can be achieved using function closures, objects, or special-purpose constructs such as MzScheme’s units (Flatt and Felleisen, 1998). 24.2 Data Abstraction with Existentials 369 ary, elements of the type are viewed concretely (with type T). Outside, they are viewed abstractly, with type A. Values of type A may be passed around, stored in data structures, etc., but not directly examined or changed—the only operations allowed on A are those provided by the ADT. For example, here is a declaration of an abstract data type of purely func- tional counters, in a pseudocode notation similar to Ada (U.S. Dept. of De- fense, 1980) or Clu (Liskov et al., 1981). ADT counter = type Counter representation Nat signature new : Counter, get : Counter→Nat, inc : Counter→Counter; operations new = 1, get = λi:Nat. i, inc = λi:Nat. succ(i); counter.get (counter.inc counter.new); The abstract type name is Counter; its concrete representation is Nat. The implementations of the operations deal with Counter objects concretely, as Nats: new is just the constant 1; the inc operation is the successor function; get is the identity. The signature section specifies how these operations are to be used externally, replacing some instances of Nat in their concrete types by Counter. The abstraction boundary extends from the ADT keyword to the terminating semicolon; in the remainder of the program (i.e., the last line), the association between Counter and Nat is broken, so that the only thing that can be done with the constant counter.new is to use it as an argument to counter.get or counter.inc. We can translate this pseudocode almost symbol for symbol into our cal- culus with existentials. We first create an existential package containing the internals of the ADT: counterADT = {*Nat, {new = 1, get = λi:Nat. i, inc = λi:Nat. succ(i)}} as {∃Counter, {new: Counter, get: Counter→Nat, inc: Counter→Counter}}; 370 24 Existential Types ñ counterADT : {∃Counter, {new:Counter,get:Counter→Nat,inc:Counter→Counter}} We then open the package, introducing the type variable Counter as a place- holder for the hidden representation type of the package and a term variable counter providing access to the operations: let {Counter,counter} = counterADT in counter.get (counter.inc counter.new); ñ 2 : Nat The version using existential types is slightly harder on the eye, compared to the syntactically sugared pseudocode, but the two are identical in structure. In general, the body of the let that opens the existential package contains the whole remainder of the program: let {Counter,counter} = in

In the remainder, the type name Counter can be used just like the base types

built into the language. We can define functions that operate on counters:

let {Counter,counter}=counterADT in

let add3 = λc:Counter. counter.inc (counter.inc (counter.inc c)) in

counter.get (add3 counter.new);

ñ 4 : Nat

We can even define new abstract data types whose representation involves

counters. For example, the following program defines an ADT of flip-flops,

using a counter as its (not particularly efficient) representation type:

let {Counter,counter} = counterADT in

let {FlipFlop,flipflop} =

{*Counter,

{new = counter.new,

read = λc:Counter. iseven (counter.get c),

toggle = λc:Counter. counter.inc c,

reset = λc:Counter. counter.new}}

as {∃FlipFlop,

{new: FlipFlop, read: FlipFlop→Bool,

toggle: FlipFlop→FlipFlop, reset: FlipFlop→FlipFlop}} in

flipflop.read (flipflop.toggle (flipflop.toggle flipflop.new));

ñ false : Bool

24.2 Data Abstraction with Existentials 371

In this way, a large program can be broken up into a long sequence of ATD

declarations, each using the types and operations provided by its predeces-

sors to implement its own, and packaging these up for its successors as a

clean, well-defined abstraction.

A key property of the kind of information hiding we are doing here is rep-

resentation independence. We can substitute an alternative implementation

of the Counter ADT—for example, one where the internal representation is a

record containing a Nat rather than just a single Nat,

counterADT =

{*{x:Nat},

{new = {x=1},

get = λi:{x:Nat}. i.x,

inc = λi:{x:Nat}. {x=succ(i.x)}}}

as {∃Counter,

{new: Counter, get: Counter→Nat, inc: Counter→Counter}};

ñ counterADT : {∃Counter,

{new:Counter,get:Counter→Nat,inc:Counter→Counter}}

in complete confidence that the whole program will remain typesafe, since

we are guaranteed that the rest of the program cannot access instances of

Counter except using get and inc.

Experience has shown that a programming style based on abstract data

types can yield huge improvements in robustness and maintainability of large

systems. There are several reasons for this. First, this style limits the scope

of changes to the program. As we saw just above, we can replace one imple-

mentation of an ADT by another, possibly changing both its concrete repre-

sentation type and the implementations of its operations, without affecting

the rest of the program, because the typing rules for existential packages

ensure that the rest of the program cannot depend on the ADT’s internal rep-

resentation. Second, it encourages programmers to limit the dependencies

between the parts of a program by making the signatures of ADTs as small

as possible. Finally, and perhaps most importantly, by making the signatures

of the operations explicit, it forces programmers to think about designing

abstractions.

24.2.1 Exercise [Recommended, «««]: Follow the model of the above example to

define an abstract data type of stacks of numbers, with operations new, push,

top (returning the current top element), pop (returning a new stack with-

out the top element), and isempty. Use the List type introduced in Exer-

cise 23.4.3 as the underlying representation. Write a simple main program

that creates a stack, pushes a couple of numbers onto it, and gets its top

372 24 Existential Types

element. This exercise is best done on-line. Use the fullomega checker and

copy the contents of the file test.f (which contains definitions of the List

constructor and associated operations) to the top of your own input file. �

24.2.2 Exercise [Recommended, ««]: Build an ADT of mutable counters, using the

reference cells defined in Chapter 13. Change new from a constant to a func-

tion taking a Unit argument and returning a Counter, and change the re-

sult type of the inc operation to Unit instead of Counter. (The fullomega

checker provides references in addition to existentials.) �

Existential Objects

The “pack and then open” idiom that we saw in the last subsection is the

hallmark of ADT-style programming using existential packages. A package

defines an abstract type and its associated operations, and we open each

package immediately after it is built, binding a type variable for the abstract

type and exposing the ADT’s operations abstractly. In this section, we show

how a simple form of object-style data abstraction can also be viewed as a

different programming idiom based on existentials. This object model is de-

veloped further in Chapter 32.

We will again use simple counters as our running example, as we did both

in the existential ADTs above and in our earlier encounters with objects in

Chapters 18 and 19. We again choose a purely functional style, where sending

the message inc to a counter does not change its internal state in-place, but

rather returns a fresh counter object with incremented internal state.

A counter object comprises two basic components: a number (its internal

state), and a pair of methods, get and inc, that can be used to manipulate the

state. We also need to ensure that the only way that the state can be queried

or updated is by using one of these two methods. This can be accomplished

by wrapping the state and methods in an existential package, abstracting the

type of the state. For example, a counter object holding the value 5 might be

written

c = {*Nat,

{state = 5,

methods = {get = λx:Nat. x,

inc = λx:Nat. succ(x)}}}

as Counter;

where:

Counter = {∃X, {state:X, methods: {get:X→Nat, inc:X→X}}};

24.2 Data Abstraction with Existentials 373

To use a method of a counter object, we open the existential and apply the

appropriate element of its methods to its state field. For example, to get the

current value of c we can write:

let {X,body} = c in body.methods.get(body.state);

ñ 5 : Nat

More generally, we can define a little function that “sends the get message”

to any counter:

sendget = λc:Counter.

let {X,body} = c in

body.methods.get(body.state);

ñ sendget : Counter → Nat

Invoking the inc method of a counter object is a little more complicated. If

we simply do the same as for get, the typechecker complains

let {X,body} = c in body.methods.inc(body.state);

ñ Error: Scoping error!

because the type variable X appears free in the type of the body of the let. In-

deed, what we’ve written doesn’t make intuitive sense either, since the result

of the inc method is a bare internal state, not an object. To satisfy both the

typechecker and our informal understanding of what invoking inc should do,

we must take this fresh internal state and repackage it as a counter object,

using the same record of methods and the same internal state type as in the

original object:

c1 = let {X,body} = c in

{*X,

{state = body.methods.inc(body.state),

methods = body.methods}}

as Counter;

More generally, to “send the inc message” to a counter, we can write:

sendinc = λc:Counter.

let {X,body} = c in

{*X,

{state = body.methods.inc(body.state),

methods = body.methods}}

as Counter;

ñ sendinc : Counter → Counter

374 24 Existential Types

More complex operations on counters can be implemented in terms of these

two basic operations:

add3 = λc:Counter. sendinc (sendinc (sendinc c));

ñ add3 : Counter → Counter

24.2.3 Exercise [Recommended, «««]: Implement FlipFlop objects with Counter

objects as their internal representation type, using the FlipFlop ADT above

as a model. �

24.2.4 Exercise [Recommended, ««]: Use the fullomega checker to implement a

stateful variant of Counter objects, following Exercise 24.2.2. �

Objects vs. ADTs

The examples in the previous section do not constitute a full-blown model

of object-oriented programming. Many of the features that we saw in Chap-

ters 18 and 19, including subtyping, classes, inheritance, and recursion via

self and super, are missing here. We will come back to modeling these fea-

tures in Chapter 32, when we have added some necessary refinements to our

type system. But there are already several interesting comparisons to be made

between these simple objects and the ADTs discussed previously.

At the coarsest level, the two programming idioms fall at opposite ends of a

spectrum: when programming with ADTs, packages are opened immediately

after they are built; on the other hand, when packages are used to model

objects they are kept closed as long as possible—until the moment when they

must be opened so that one of the methods can be applied to the internal

state.

A consequence of this difference is that “the abstract type of counters”

refers to different things in the two styles. In an ADT-style program, the

counter values manipulated by client code such as the add3 function are el-

ements of the underlying representation type (e.g., simple numbers). In an

object-style program, each counter is a whole package—including not only

a number, but also the implementations of the get and inc methods. This

stylistic difference is reflected in the fact that, in the ADT style, the type

Counter is a bound type variable introduced by the let construct, while in

the object style Counter stands for the whole existential type

{∃X, {state:X, methods: {get:X→Nat,inc:X→X}}}.

Thus, at run time, all the counter values generated from the counter ADT are

just bare elements of the same internal representation type, and there is a sin-

gle implementation of the counter operations that works on this internal rep-

resentation. By contrast, each counter object carries its own representation

24.2 Data Abstraction with Existentials 375

type together with its own set of methods that work for this representation

type.

These differences between objects and ADTs lead to contrasting pragmatic

advantages. One obvious one is that, since each object chooses its own repre-

sentation and carries its own operations, a single program can freely intermix

many different implementations of the same object type. This is particularly

convenient in the presence of subtyping and inheritance: we can define a sin-

gle, general class of objects and then produce many different refinements,

each with its own slightly (or completely) different representation. Since in-

stances of these refined classes all share the same general type, they can be

manipulated by the same generic code, stored together in lists, etc.

For example, a user-interface library may define a generic Window class,

with subclasses like TextWindow, ContainerWindow, ScrollableWindow,

TitledWindow, DialogBox, etc. Each of these subclasses will include its own

particular instance variables (e.g., a TextWindow may use a String instance

variable to represent its current contents, whereas a ContainerWindow might

use a list of Window objects), and provide specialized implementations of op-

erations like repaint and handleMouseEvent. Defining Window as an ADT,

on the other hand, leads to a less flexible structure. The concrete representa-

tion type of Window will need to include a variant type (§11.10) with one case

for each specific sort of window, carrying the specialized data relevant to that

type of window. Operations like repaint will perform a case on the variant

and execute the appropriate specialized code. If there are many special forms

of windows, this monolithic declaration of the Window ADT can easily grow

to be quite large and unwieldy.

A second major pragmatic difference between objects and ADTs concerns

the status of binary operations—operations that accept two or more argu-

ments of the same abstract type. To discuss this point coherently, we need to

distinguish between two kinds of binary operations:

• Some binary operations can be implemented entirely in terms of the pub-

licly available operations on two abstract values. For example, to imple-

ment an equality operation for counters, all we need to do is ask each for

its current value (using get) and compare the two numbers that we get

back—i.e., the equal operation can just as well live outside the abstrac-

tion boundary that protects the concrete representation of counters. We

call such operations weak binary operations.

• Other binary operations cannot be implemented without concrete, privi-

leged access to the representations of both abstract values. For example,

suppose we are implementing an abstraction representing sets of num-

bers. After scouring several algorithms textbooks, we choose a concrete

376 24 Existential Types

representation of sets as labeled trees obeying some particular complex

invariant. An efficient implementation of the union operation on two sets

will need to view both of them concretely, as trees. However, we do not

want to expose this concrete representation anywhere in the public inter-

face to our set abstraction. So we will need to arrange for union to have

privileged access to both of its arguments that is not available to ordi-

nary client code—i.e., the union operation must live inside the abstraction

boundary. We call such operations strong binary operations.

Weak binary operations are an easy case for both of the styles of abstraction

we are considering, since it does not make much difference whether we place

them inside or outside of the abstraction boundary. If we choose to place

them outside, then they may simply be defined as free-standing functions

(taking either objects or values of an ADT, as appropriate). Placing them in-

side an ADT is exactly the same (they will then have concrete access to the

representations of their arguments, even though they don’t really need it).

Placing a weak binary operation inside of an object is only slightly more de-

manding, since the type of the object now becomes recursive:4

EqCounter = {∃X, {state:X, methods: {get:X→Nat, inc:X→X,

eq:X→EqCounter→Bool}}}

.

Strong binary operations, on the other hand, cannot be expressed as meth-

ods of objects in our model. We can express their types just as we did for

weak binary methods above:

NatSet = {∃X, {state:X, methods: {empty:X, singleton:Nat→X,

member:X→Nat→Bool,

union:X→NatSet→X}}}

.

But there is no satisfactory way to implement an object of this type: all we

know about the second argument of the union operation is that it provides

the operations of NatSet, but these do not give us any way to find out what

its elements are so that we can compute the union.

24.2.5 Exercise [«]: Why can’t we use the type

NatSet = {∃X, {state:X, methods: {empty:X, singleton:Nat→X,

member:X→Nat→Bool,

union:X→X→X}}}

instead? �

4. This sort of recursion in object types interacts with inheritance in some tricky ways. See

Bruce et al. (1996).

24.3 Encoding Existentials 377

In summary, the single representations of ADTs directly support binary

operations, while the multiple representations of objects give up binary meth-

ods in return for useful flexibility. These advantages are complementary; nei-

ther style dominates the other.

One caveat should be added to this discussion. These comparisons apply

to the simple, “purist” model of objects presented earlier in the chapter. The

classes in mainstream object-oriented languages like C++ and Java are de-

signed to allow some forms of strong binary methods, and are actually best

described as a kind of compromise between the pure objects and pure ADTs

that we have seen in this chapter. In these languages, the type of an object

is exactly the name of the class from which it was instantiated, and this type

is considered distinct from the names of other classes, even if they provide

exactly the same operations (cf. §19.3). That is, a given object type in these

languages has a single implementation given by the corresponding class dec-

laration. Moreover, subclasses in these languages can add instance variables

only to those inherited from superclasses. These constraints mean that every

object belonging to type C is guaranteed to have all the instance variables

defined by the (unique) declaration of class C (and possibly some more). It

now makes sense for a method of such an object to take another C as an ar-

gument and concretely access its instance variables, as long as it uses only

instance variables defined by C. This permits strong binary operations such as

set union to be defined as methods. “Hybrid” object models of this sort have

been formalized by Pierce and Turner (1993) and Katiyar et al. (1994), and

elaborated in more detail by Fisher and Mitchell (Fisher and Mitchell, 1996,

1998; Fisher, 1996b,a).

24.3 Encoding Existentials

The encoding of pairs as a polymorphic type in §23.4 suggests a similar en-

coding for existential types in terms of universal types, using the intuition

that an element of an existential type is a pair of a type and a value:

{∃X,T}
def
= ∀Y. (∀X. T→Y) → Y.

That is, an existential package is thought of as a data value that, given a

result type and a continuation, calls the continuation to yield a final result.

The continuation takes two arguments—a type X and a value of type T—and

uses them in computing the final result.

Given this encoding of existential types, the encoding of the packaging and

unpackaging constructs is essentially forced. To encode a package

{*S,t} as {∃X,T}

378 24 Existential Types

we must use S and t to build a value of type ∀Y. (∀X. T→Y) → Y. This type

begins with a universal quantifier, the body of which is an arrow type. An

element of this type should therefore begin with two abstractions:

{*S,t} as {∃X,T}
def
= λY. λf:(∀X.T→Y). …

To complete the job, we need to return a result of type Y; clearly, the only

way to do this is to apply f to some appropriate arguments. First, we supply

the type S (this is a natural choice, being the only type we have lying around

at the moment):

{*S,t} as {∃X,T}
def
= λY. λf:(∀X.T→Y). f [S] …

Now, the type application f [S] has type [X , S](T→Y), i.e., ([X , S]T)→Y.

We can thus supply t (which, by rule T-Pack, has type [X , S]T) as the next

argument:

{*S,t} as {∃X,T}
def
= λY. λf:(∀X.T→Y). f [S] t

The type of the whole application f [S] t is now Y, as required.

To encode the unpacking construct let {X,x}=t1 in t2, we proceed simi-

larly. First, the typing rule T-Unpack tells us that t1 should have some type

{∃X,T11}, that t2 should have type T2 (under an extended context binding

X and x:T11), and that T2 is the type we expect for the whole let…in…

expression.5 As in the Church encodings in §23.4, the intuition here is that

the introduction form ({*S,t}) is encoded as an active value that “performs

its own elimination.” So the encoding of the elimination form here should

simply take the existential package t1 and apply it to enough arguments to

yield a result of the desired type T2:

let {X,x}=t1 in t2
def
= t1 …

The first argument to t1 should be the desired result type of the whole ex-

pression, i.e., T2:

let {X,x}=t1 in t2
def
= t1 [T2] …

Now, the application t1 [T2] has type (∀X. T11→T2) → T2. That is, if we can

now supply another argument of type (∀X.T11→T2), we will be finished. Such

5. Strictly speaking, the fact that the translation requires these extra bits of type information

not present in the syntax of terms means that what we are translating is actually typing deriva-

tions, not terms. We have seen a similar situation in the definition of the coercion semantics for