Concepts

We now turn to the study of subtyping, a key feature needed to support the object-oriented programming style.

A Motivating Example

Suppose we are writing a program involving two record types defined as follows:

      Person  = {name:String, age:Nat}
      Student = {name:String, age:Nat, gpa:Nat}

In the simply typed lamdba-calculus with records, the term

      (\r:Person. (r.age)+1) {name="Pat",age=21,gpa=1}

is not typable, since it applies a function that wants a two-field record to an argument that actually provides three fields, while the T_App rule demands that the domain type of the function being applied must match the type of the argument precisely. But this is silly: we're passing the function a better argument than it needs! The only thing the body of the function can possibly do with its record argument r is project the field age from it: nothing else is allowed by the type, and the presence or absence of an extra gpa field makes no difference at all. So, intuitively, it seems that this function should be applicable to any record value that has at least an age field. More generally, a record with more fields is "at least as good in any context" as one with just a subset of these fields, in the sense that any value belonging to the longer record type can be used safely in any context expecting the shorter record type. If the context expects something with the shorter type but we actually give it something with the longer type, nothing bad will happen (formally, the program will not get stuck). The principle at work here is called subtyping. We say that "S is a subtype of T", written S <: T, if a value of type S can safely be used in any context where a value of type T is expected. The idea of subtyping applies not only to records, but to all of the type constructors in the language — functions, pairs, etc. Safe substitution principle:

• S is a subtype of T, written S <: T, if a value of type S can safely be used in any context where a value of type T is expected.

Subtyping and Object-Oriented Languages

Subtyping plays a fundamental role in many programming languages — in particular, it is closely related to the notion of subclassing in object-oriented languages. An object in Java, C#, etc. can be thought of as a record, some of whose fields are functions ("methods") and some of whose fields are data values ("fields" or "instance variables"). Invoking a method m of an object o on some arguments a₁..an roughly consists of projecting out the m field of o and applying it to a₁..an. The type of an object is called a class — or, in some languages, an interface. It describes which methods and which data fields the object offers. Classes and interfaces are related by the subclass and subinterface relations. An object belonging to a subclass (or subinterface) is required to provide all the methods and fields of one belonging to a superclass (or superinterface), plus possibly some more. The fact that an object from a subclass can be used in place of one from a superclass provides a degree of flexibility that is extremely handy for organizing complex libraries. For example, a GUI toolkit like Java's Swing framework might define an abstract interface Component that collects together the common fields and methods of all objects having a graphical representation that can be displayed on the screen and interact with the user, such as the buttons, checkboxes, and scrollbars of a typical GUI. A method that relies only on this common interface can now be applied to any of these objects. Of course, real object-oriented languages include many other features besides these. For example, fields can be updated. Fields and methods can be declared private. Classes can give initializers that are used when constructing objects. Code in subclasses can cooperate with code in superclasses via inheritance. Classes can have static methods and fields. Etc., etc. To keep things simple here, we won't deal with any of these issues — in fact, we won't even talk any more about objects or classes. (There is a lot of discussion in [Pierce 2002], if you are interested.) Instead, we'll study the core concepts behind the subclass / subinterface relation in the simplified setting of the STLC.

The Subsumption Rule

Our goal for this chapter is to add subtyping to the simply typed lambda-calculus (with some of the basic extensions from MoreStlc). This involves two steps:

• Defining a binary subtype relation between types.
• Enriching the typing relation to take subtyping into account.

The second step is actually very simple. We add just a single rule to the typing relation: the so-called rule of subsumption:

Gamma ⊢ t ∈ S     S <: T	(T_Sub)
Gamma ⊢ t ∈ T

This rule says, intuitively, that it is OK to "forget" some of what we know about a term. For example, we may know that t is a record with two fields (e.g., S = {x:A→A, y:B→B}), but choose to forget about one of the fields (T = {y:B→B}) so that we can pass t to a function that requires just a single-field record.

The Subtype Relation

The first step — the definition of the relation S <: T — is where all the action is. Let's look at each of the clauses of its definition.

Structural Rules

To start off, we impose two "structural rules" that are independent of any particular type constructor: a rule of transitivity, which says intuitively that, if S is better (richer, safer) than U and U is better than T, then S is better than T...

S <: U    U <: T	(S_Trans)
S <: T

... and a rule of reflexivity, since certainly any type T is as good as itself:

	(S_Refl)
T <: T

Products

Now we consider the individual type constructors, one by one, beginning with product types. We consider one pair to be a subtype of another if each of its components is.

S1 <: T1    S2 <: T2	(S_Prod)
S1 * S2 <: T1 * T2

Arrows

The subtyping rule for arrows is a little less intuitive. Suppose we have functions f and g with these types: That is, f is a function that yields a record of type Student, and g is a (higher-order) function that expects its argument to be a function yielding a record of type Person. Also suppose that Student is a subtype of Person. Then the application g f is safe even though their types do not match up precisely, because the only thing g can do with f is to apply it to some argument (of type C); the result will actually be a Student, while g will be expecting a Person, but this is safe because the only thing g can then do is to project out the two fields that it knows about (name and age), and these will certainly be among the fields that are present. This example suggests that the subtyping rule for arrow types should say that two arrow types are in the subtype relation if their results are:

S2 <: T2	(S_Arrow_Co)
S1 → S2 <: S1 → T2

We can generalize this to allow the arguments of the two arrow types to be in the subtype relation as well:

T1 <: S1    S2 <: T2	(S_Arrow)
S1 → S2 <: T1 → T2

But notice that the argument types are subtypes "the other way round": in order to conclude that S₁→S₂ to be a subtype of T₁→T₂, it must be the case that T₁ is a subtype of S₁. The arrow constructor is said to be contravariant in its first argument and covariant in its second. Here is an example that illustrates this: The application g f is safe, because the only thing the body of g can do with f is to apply it to some argument of type Student. Since f requires records having (at least) the fields of a Person, this will always work. So Person → C is a subtype of Student → C since Student is a subtype of Person. The intuition is that, if we have a function f of type S₁→S₂, then we know that f accepts elements of type S₁; clearly, f will also accept elements of any subtype T₁ of S₁. The type of f also tells us that it returns elements of type S₂; we can also view these results belonging to any supertype T₂ of S₂. That is, any function f of type S₁→S₂ can also be viewed as having type T₁→T₂.

Records

What about subtyping for record types? The basic intuition is that it is always safe to use a "bigger" record in place of a "smaller" one. That is, given a record type, adding extra fields will always result in a subtype. If some code is expecting a record with fields x and y, it is perfectly safe for it to receive a record with fields x, y, and z; the z field will simply be ignored. For example, This is known as "width subtyping" for records. We can also create a subtype of a record type by replacing the type of one of its fields with a subtype. If some code is expecting a record with a field x of type T, it will be happy with a record having a field x of type S as long as S is a subtype of T. For example, This is known as "depth subtyping". Finally, although the fields of a record type are written in a particular order, the order does not really matter. For example, This is known as "permutation subtyping". We could formalize these requirements in a single subtyping rule for records as follows:

∀jk in j1..jn,
∃ip in i1..im, such that
jk=ip and Sp <: Tk	(S_Rcd)
{i1:S1...im:Sm} <: {j1:T1...jn:Tn}

That is, the record on the left should have all the field labels of the one on the right (and possibly more), while the types of the common fields should be in the subtype relation. However, this rule is rather heavy and hard to read, so it is often decomposed into three simpler rules, which can be combined using S_Trans to achieve all the same effects. First, adding fields to the end of a record type gives a subtype:

n > m	(S_RcdWidth)
{i1:T1...in:Tn} <: {i1:T1...im:Tm}

We can use S_RcdWidth to drop later fields of a multi-field record while keeping earlier fields, showing for example that {age:Nat,name:String} <: {age:Nat}. Second, subtyping can be applied inside the components of a compound record type:

S1 <: T1  ...  Sn <: Tn	(S_RcdDepth)
{i1:S1...in:Sn} <: {i1:T1...in:Tn}

For example, we can use S_RcdDepth and S_RcdWidth together to show that {y:Student, x:Nat} <: {y:Person}. Third, subtyping can reorder fields. For example, we want {name:String, gpa:Nat, age:Nat} <: Person. (We haven't quite achieved this yet: using just S_RcdDepth and S_RcdWidth we can only drop fields from the end of a record type.) So we add:

{i1:S1...in:Sn} is a permutation of {j1:T1...jn:Tn}	(S_RcdPerm)
{i1:S1...in:Sn} <: {j1:T1...jn:Tn}

It is worth noting that full-blown language designs may choose not to adopt all of these subtyping rules. For example, in Java:

• Each class member (field or method) can be assigned a single index, adding new indices "on the right" as more members are added in subclasses (i.e., no permutation for classes).
• A class may implement multiple interfaces — so-called "multiple inheritance" of interfaces (i.e., permutation is allowed for interfaces).
• In early versions of Java, a subclass could not change the argument or result types of a method of its superclass (i.e., no depth subtyping or no arrow subtyping, depending how you look at it).

Exercise: 2 stars, standard, recommended (arrow_sub_wrong)

Suppose we had incorrectly defined subtyping as covariant on both the right and the left of arrow types:

S1 <: T1    S2 <: T2	(S_Arrow_wrong)
S1 → S2 <: T1 → T2

Give a concrete example of functions f and g with the following types... ... such that the application g f will get stuck during execution. (Use informal syntax. No need to prove formally that the application gets stuck.)

Summary

In summary, we form the STLC with subtyping by starting with the pure STLC (over some set of base types) and then...

• adding a base type Top,
• adding the rule of subsumption

  Gamma ⊢ t ∈ S     S <: T	(T_Sub)
  Gamma ⊢ t ∈ T

  to the typing relation, and
• defining a subtype relation as follows:

  S <: U    U <: T	(S_Trans)
  S <: T

  	(S_Refl)
  T <: T

  	(S_Top)
  S <: Top

  S1 <: T1    S2 <: T2	(S_Prod)
  S1 * S2 <: T1 * T2

  T1 <: S1    S2 <: T2	(S_Arrow)
  S1 → S2 <: T1 → T2

  n > m	(S_RcdWidth)
  {i1:T1...in:Tn} <: {i1:T1...im:Tm}

  S1 <: T1  ...  Sn <: Tn	(S_RcdDepth)
  {i1:S1...in:Sn} <: {i1:T1...in:Tn}

  {i1:S1...in:Sn} is a permutation of {j1:T1...jn:Tn}	(S_RcdPerm)
  {i1:S1...in:Sn} <: {j1:T1...jn:Tn}

Exercises

Exercise: 1 star, standard, optional (subtype_instances_tf_1)

Suppose we have types S, T, U, and V with S <: T and U <: V. Which of the following subtyping assertions are then true? Write true or false after each one. (A, B, and C here are base types like Bool, Nat, etc.)

• T→S <: T→S
• Top→U <: S→Top
• (C→C) → (A*B) <: (C→C) → (Top*B)
• T→T→U <: S→S→V
• (T→T)→U <: (S→S)→V
• ((T→S)→T)→U <: ((S→T)→S)→V
• S*V <: T*U

☐

Exercise: 2 stars, standard (subtype_order)

The following types happen to form a linear order with respect to subtyping:

• Top
• Top → Student
• Student → Person
• Student → Top
• Person → Student

Write these types in order from the most specific to the most general. Where does the type Top→Top→Student fit into this order? That is, state how Top → (Top → Student) compares with each of the five types above. It may be unrelated to some of them.

Formal Definitions

Most of the definitions needed to formalize what we've discussed above — in particular, the syntax and operational semantics of the language — are identical to what we saw in the last chapter. We just need to extend the typing relation with the subsumption rule and add a new Inductive definition for the subtyping relation. Let's first do the identical bits.

Core Definitions

Syntax

In the rest of the chapter, we formalize just base types, booleans, arrow types, Unit, and Top, omitting record types and leaving product types as an exercise. For the sake of more interesting examples, we'll add an arbitrary set of base types like String, Float, etc. (Since they are just for examples, we won't bother adding any operations over these base types, but we could easily do so.)

Substitution

The definition of substitution remains exactly the same as for the pure STLC.

Reduction

Likewise the definitions of the value property and the step relation.

Subtyping

Now we come to the interesting part. We begin by defining the subtyping relation and developing some of its important technical properties. The definition of subtyping is just what we sketched in the motivating discussion.

Note that we don't need any special rules for base types (Bool and Base): they are automatically subtypes of themselves (by S_Refl) and Top (by S_Top), and that's all we want.

Exercise: 2 stars, standard, optional (subtyping_judgements)

(Leave this exercise Admitted until after you have finished adding product types to the language — see exercise products — at least up to this point in the file). Recall that, in chapter MoreStlc, the optional section "Encoding Records" describes how records can be encoded as pairs. Using this encoding, define pair types representing the following record types:

Now use the definition of the subtype relation to prove the following:

Typing

The only change to the typing relation is the addition of the rule of subsumption, T_Sub.

The following hints help auto and eauto construct typing derivations. They are only used in a few places, but they give a nice illustration of what auto can do with a bit more programming. See chapter UseAuto for more on hints.

Do the following exercises after you have added product types to the language. For each informal typing judgement, write it as a formal statement in Coq and prove it.

Exercise: 1 star, standard, optional (typing_example_0)

Properties

The fundamental properties of the system that we want to check are the same as always: progress and preservation. Unlike the extension of the STLC with references (chapter References), we don't need to change the statements of these properties to take subtyping into account. However, their proofs do become a little bit more involved.

Inversion Lemmas for Subtyping

Before we look at the properties of the typing relation, we need to establish a couple of critical structural properties of the subtype relation:

• Bool is the only subtype of Bool, and
• every subtype of an arrow type is itself an arrow type.

These are called inversion lemmas because they play a similar role in proofs as the built-in inversion tactic: given a hypothesis that there exists a derivation of some subtyping statement S <: T and some constraints on the shape of S and/or T, each inversion lemma reasons about what this derivation must look like to tell us something further about the shapes of S and T and the existence of subtype relations between their parts.

Exercise: 2 stars, standard, optional (sub_inversion_Bool)

Exercise: 3 stars, standard (sub_inversion_arrow)

Canonical Forms

The proof of the progress theorem — that a well-typed non-value can always take a step — doesn't need to change too much: we just need one small refinement. When we're considering the case where the term in question is an application t₁ t₂ where both t₁ and t₂ are values, we need to know that t₁ has the form of a lambda-abstraction, so that we can apply the ST_AppAbs reduction rule. In the ordinary STLC, this is obvious: we know that t₁ has a function type T₁₁→T₁₂, and there is only one rule that can be used to give a function type to a value — rule T_Abs — and the form of the conclusion of this rule forces t₁ to be an abstraction. In the STLC with subtyping, this reasoning doesn't quite work because there's another rule that can be used to show that a value has a function type: subsumption. Fortunately, this possibility doesn't change things much: if the last rule used to show Gamma ⊢ t₁ ∈ T₁₁→T₁₂ is subsumption, then there is some sub-derivation whose subject is also t₁, and we can reason by induction until we finally bottom out at a use of T_Abs. This bit of reasoning is packaged up in the following lemma, which tells us the possible "canonical forms" (i.e., values) of function type.

Exercise: 3 stars, standard, optional (canonical_forms_of_arrow_types)

Progress

The proof of progress now proceeds just like the one for the pure STLC, except that in several places we invoke canonical forms lemmas... Theorem (Progress): For any term t and type T, if empty ⊢ t ∈ T then t is a value or t --> t' for some term t'. Proof: Let t and T be given, with empty ⊢ t ∈ T. Proceed by induction on the typing derivation. The cases for T_Abs, T_Unit, T_True and T_False are immediate because abstractions, unit, tru, and fls are already values. The T_Var case is vacuous because variables cannot be typed in the empty context. The remaining cases are more interesting:

• If the last step in the typing derivation uses rule T_App, then there are terms t₁ t₂ and types T₁ and T₂ such that t = t₁ t₂, T = T₂, empty ⊢ t₁ ∈ T₁ → T₂, and empty ⊢ t₂ ∈ T₁. Moreover, by the induction hypothesis, either t₁ is a value or it steps, and either t₂ is a value or it steps. There are three possibilities to consider:
  • Suppose t₁ --> t₁' for some term t₁'. Then t₁ t₂ --> t₁' t₂ by ST_App1.
  • Suppose t₁ is a value and t₂ --> t₂' for some term t₂'. Then t₁ t₂ --> t₁ t₂' by rule ST_App2 because t₁ is a value.
  • Finally, suppose t₁ and t₂ are both values. By the canonical forms lemma for arrow types, we know that t₁ has the form \x:S₁.s2 for some x, S₁, and s₂. But then (\x:S₁.s2) t₂ --> [x:=t₂]s₂ by ST_AppAbs, since t₂ is a value.
• If the final step of the derivation uses rule T_Test, then there are terms t₁, t₂, and t₃ such that t = test t₁ then t₂ else t₃, with empty ⊢ t₁ ∈ Bool and with empty ⊢ t₂ ∈ T and empty ⊢ t₃ ∈ T. Moreover, by the induction hypothesis, either t₁ is a value or it steps.
  • If t₁ is a value, then by the canonical forms lemma for booleans, either t₁ = tru or t₁ = fls. In either case, t can step, using rule ST_TestTrue or ST_TestFalse.
  • If t₁ can step, then so can t, by rule ST_Test.
• If the final step of the derivation is by T_Sub, then there is a type S such that S <: T and empty ⊢ t ∈ S. The desired result is exactly the induction hypothesis for the typing subderivation.

Formally:

Inversion Lemmas for Typing

The proof of the preservation theorem also becomes a little more complex with the addition of subtyping. The reason is that, as with the "inversion lemmas for subtyping" above, there are a number of facts about the typing relation that are immediate from the definition in the pure STLC (formally: that can be obtained directly from the inversion tactic) but that require real proofs in the presence of subtyping because there are multiple ways to derive the same has_type statement. The following inversion lemma tells us that, if we have a derivation of some typing statement Gamma ⊢ \x:S₁.t2 ∈ T whose subject is an abstraction, then there must be some subderivation giving a type to the body t₂. Lemma: If Gamma ⊢ \x:S₁.t2 ∈ T, then there is a type S₂ such that x⊢>S₁; Gamma ⊢ t₂ ∈ S₂ and S₁ → S₂ <: T. (Notice that the lemma does not say, "then T itself is an arrow type" — this is tempting, but false!) Proof: Let Gamma, x, S₁, t₂ and T be given as described. Proceed by induction on the derivation of Gamma ⊢ \x:S₁.t2 ∈ T. Cases T_Var, T_App, are vacuous as those rules cannot be used to give a type to a syntactic abstraction.

• If the last step of the derivation is a use of T_Abs then there is a type T₁₂ such that T = S₁ → T₁₂ and x:S₁; Gamma ⊢ t₂ ∈ T₁₂. Picking T₁₂ for S₂ gives us what we need: S₁ → T₁₂ <: S₁ → T₁₂ follows from S_Refl.

• If the last step of the derivation is a use of T_Sub then there is a type S such that S <: T and Gamma ⊢ \x:S₁.t2 ∈ S. The IH for the typing subderivation tells us that there is some type S₂ with S₁ → S₂ <: S and x:S₁; Gamma ⊢ t₂ ∈ S₂. Picking type S₂ gives us what we need, since S₁ → S₂ <: T then follows by S_Trans.

Formally:

Similarly...

The inversion lemmas for typing and for subtyping between arrow types can be packaged up as a useful "combination lemma" telling us exactly what we'll actually require below.

Context Invariance

The context invariance lemma follows the same pattern as in the pure STLC.

Substitution

The substitution lemma is proved along the same lines as for the pure STLC. The only significant change is that there are several places where, instead of the built-in inversion tactic, we need to use the inversion lemmas that we proved above to extract structural information from assumptions about the well-typedness of subterms.