Subtyping


(* $Date: 2011-05-07 21:28:52 -0400 (Sat, 07 May 2011) $ *)

Require Export MoreStlc.

Concepts

We now turn to the study of subtyping, perhaps the most characteristic feature of the static type systems used by many recently designed programming languages.

A Motivating Example

In the simply typed lamdba-calculus with records, the term
    (\r:{y:Nat}. (r.y)+1) {x=10,y=11}
is not typable: it involves an application of a function that wants a one-field record to an argument that actually provides two 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 y from it: nothing else is allowed by the type. So the presence or absence of an extra x field should make no difference at all. So, intuitively, it seems that this function should be applicable to any record value that has at least a y field.
Looking at the same thing from another point of view, 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 general principle at work here is called subtyping. We say that "S is a subtype of T", informally 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.

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 a1..an consists of projecting out the m field of o and applying it to a1..an.
The type of an object can be given as either a class or an interface. Both of these provide a description of 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 (or sub-interface) can be used in place of one from a superclass (or super-interface) provides a degree of flexibility that is is extremely handy for organizing complex libraries. For example, a graphical user interface 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 that can interact with the user. Examples of such object would include 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. Fields can be updated. Fields and methods can be declared private. Classes also give code that is used when constructing objects and implementing their methods, and the code in subclasses cooperate with code in superclasses via inheritance. Classes can have static methods and fields, initializers, 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 Types and Programming Languages, 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 products). 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:
Γ  t : S     S <: T (T_Sub)  

Γ  t : T
This rule says, intuitively, that we can "forget" some of the information that we know about a term. For example, we may know that t is a record with two fields (e.g., S = {x:AA, y:BB}], but choose to forget about one of the fields (T = {y:BB}) so that we can pass t to a function that expects 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.

Products

First, product types. We consider one pair to be "better than" another if each of its components is.
S1 <: T1    S2 <: T2 (S_Prod)  

S1*S2 <: T1*T2

Arrows

Suppose we have two functions f and g with these types:
       f : C -> {x:A,y:B} 
       g : (C->{y:B}) -> D
That is, f is a function that yields a record of type {x:A,y:B}, and g is a higher-order function that expects its (function) argument to yield a record of type {y:B}. (And suppose, even though we haven't yet discussed subtyping for records, that {x:A,y:B} is a subtype of {y:B}) 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 two-field record, while g will be expecting only a record with a single field, but this is safe because the only thing g can then do is to project out the single field that it knows about, and this will certainly be among the two 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_Arrow2)  

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
Notice, here, that the argument types are subtypes "the other way round": in order to conclude that S1S2 to be a subtype of T1T2, it must be the case that T1 is a subtype of S1. The arrow constructor is said to be contravariant in its first argument and covariant in its second.
The intuition is that, if we have a function f of type S1S2, 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 S1S2 can also be viewed as having type T1T2.

Top

It is natural to give the subtype relation a maximal element — a type that lies above every other type and is inhabited by all (well-typed) values. We do this by adding to the language one new type constant, called Top, together with a subtyping rule that places it above every other type in the subtype relation:
   (S_Top)  

S <: Top
The Top type is an analog of the Object type in Java and C#.

Structural Rules

To finish off the subtype relation, we add two "structural rules" that are independent of any particular type constructor: a rule of transitivity, which says intuitively that, if S is better 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 any type T is always just as good as itself:
   (S_Refl)  

T <: T

Records

What about subtyping for record types?
The basic intuition about subtyping for record types 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,
       {x:Nat,y:Bool} <: {x:Nat}
       {x:Nat} <: {}
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,
       {a:{x:Nat}} <: {a:{}}
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,
       {x:Nat,y:Bool} <: {y:Bool,x:Nat}
This is known as "permutation subtyping".
We could try formalizing these requirements in a single subtyping rule for records as follows:
for each 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. If we like, we can decompose it 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 {y:B, x:A} <: {y:B}.
Second, we can apply subtyping 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:{z:B}, x:A} <: {y:{}}.
Third, we need to be able to reorder fields. The example we originally had in mind was {x:A,y:B} <: {y:B}. 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 need:
{i1:S1...in:Sn} is a permutation of {i1:T1...in:Tn} (S_RcdPerm)  

{i1:S1...in:Sn} <: {i1:T1...in:Tn}
Further examples:
  • {x:A,y:B} <: {y:B,x:A}.
  • {}->{j:A} <: {k:B}Top
  • Top->{k:A,j:B} <: C->{j:B}
It is worth noting that real languages may choose not to adopt all of these subtyping rules. For example, in Java:
  • A subclass may 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).
  • Each class has just one superclass ("single inheritance" of classes)
    • 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).

Records, via Products and Top (optional)

Exactly how we formalize all this depends on how we are choosing to formalize records and their types. If we are treating them as part of the core language, then we need to write down subtyping rules for them. The file RecordSub.v shows how this extension works.
On the other hand, if we are treating them as a derived form that is desugared in the parser, then we shouldn't need any new rules: we should just check that the existing rules for subtyping product and Unit types give rise to reasonable rules for record subtyping via this encoding. To do this, we just need to make one small change to the encoding described earlier: instead of using Unit as the base case in the encoding of tuples and the "don't care" placeholder in the encoding of records, we use Top. So:
    {a:Nat, b:Nat} ----> {Nat,Nat}       i.e. (Nat,(Nat,Top))
    {c:Nat, a:Nat} ----> {Nat,Top,Nat}   i.e. (Nat,(Top,(Nat,Top)))
The encoding of record values doesn't change at all. It is easy (and instructive) to check that the subtyping rules above are validated by the encoding. For the rest of this chapter, we'll follow this approach.

Core definitions

We've already sketched the significant extensions that we'll need to make to the STLC: (1) add the subtype relation and (2) extend the typing relation with the rule of subsumption. To make everything work smoothly, we'll also implement some technical improvements to the presentation from the last chapter. The rest of the definitions — in particular, the syntax and operational semantics of the language — are identical to what we saw in the last chapter. Let's first do the identical bits.

Syntax

Just for the sake of more interesting examples, we'll make one more very small extension to the pure STLC: an arbitrary set of additional base types like String, Person, Window, etc. We won't bother adding any constants belonging to these types or any operators on them, but we could easily do so.
In the rest of the chapter, we formalize just base types, booleans, arrow types, Unit, and Top, leaving product types as an exercise.

Inductive ty : Type :=
  | ty_Top : ty
  | ty_Bool : ty
  | ty_base : id ty
  | ty_arrow : ty ty ty
  | ty_Unit : ty
.

Tactic Notation "ty_cases" tactic(first) ident(c) :=
  first;
  [ Case_aux c "ty_Top" | Case_aux c "ty_Bool"
  | Case_aux c "ty_base" | Case_aux c "ty_arrow"
  | Case_aux c "ty_Unit" |
  ].

Inductive tm : Type :=
  | tm_var : id tm
  | tm_app : tm tm tm
  | tm_abs : id ty tm tm
  | tm_true : tm
  | tm_false : tm
  | tm_if : tm tm tm tm
  | tm_unit : tm
.

Tactic Notation "tm_cases" tactic(first) ident(c) :=
  first;
  [ Case_aux c "tm_var" | Case_aux c "tm_app"
  | Case_aux c "tm_abs" | Case_aux c "tm_true"
  | Case_aux c "tm_false" | Case_aux c "tm_if"
  | Case_aux c "tm_unit"
  ].

Substitution

The definition of substitution remains the same as for the ordinary STLC.

Fixpoint subst (s:tm) (x:id) (t:tm) : tm :=
  match t with
  | tm_var y =>
      if beq_id x y then s else t
  | tm_abs y T t1 =>
      tm_abs y T (if beq_id x y then t1 else (subst s x t1))
  | tm_app t1 t2 =>
      tm_app (subst s x t1) (subst s x t2)
  | tm_true =>
      tm_true
  | tm_false =>
      tm_false
  | tm_if t1 t2 t3 =>
      tm_if (subst s x t1) (subst s x t2) (subst s x t3)
  | tm_unit =>
      tm_unit
  end.

Reduction

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

Inductive value : tm Prop :=
  | v_abs : x T t,
      value (tm_abs x T t)
  | t_true :
      value tm_true
  | t_false :
      value tm_false
  | v_unit :
      value tm_unit
.

Hint Constructors value.

Reserved Notation "t1 '' t2" (at level 40).

Inductive step : tm tm Prop :=
  | ST_AppAbs : x T t12 v2,
         value v2
         (tm_app (tm_abs x T t12) v2) (subst v2 x t12)
  | ST_App1 : t1 t1' t2,
         t1 t1'
         (tm_app t1 t2) (tm_app t1' t2)
  | ST_App2 : v1 t2 t2',
         value v1
         t2 t2'
         (tm_app v1 t2) (tm_app v1 t2')
  | ST_IfTrue : t1 t2,
      (tm_if tm_true t1 t2) t1
  | ST_IfFalse : t1 t2,
      (tm_if tm_false t1 t2) t2
  | ST_If : t1 t1' t2 t3,
      t1 t1'
      (tm_if t1 t2 t3) (tm_if t1' t2 t3)
where "t1 '' t2" := (step t1 t2).

Tactic Notation "step_cases" tactic(first) ident(c) :=
  first;
  [ Case_aux c "ST_AppAbs" | Case_aux c "ST_App1"
  | Case_aux c "ST_App2" | Case_aux c "ST_IfTrue"
  | Case_aux c "ST_IfFalse" | Case_aux c "ST_If"
  ].

Hint Constructors step.

Now we come to the interesting part. We begin by defining the subtyping relation and developing some of its important technical properties.

Definition

The definition of subtyping is just what we sketched in the motivating discussion.

Inductive subtype : ty ty Prop :=
  | S_Refl : T,
    subtype T T
  | S_Trans : S U T,
    subtype S U
    subtype U T
    subtype S T
  | S_Top : S,
    subtype S ty_Top
  | S_Arrow : S1 S2 T1 T2,
    subtype T1 S1
    subtype S2 T2
    subtype (ty_arrow S1 S2) (ty_arrow T1 T2)
.

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

Hint Constructors subtype.

Tactic Notation "subtype_cases" tactic(first) ident(c) :=
  first;
  [ Case_aux c "S_Refl" | Case_aux c "S_Trans"
  | Case_aux c "S_Top" | Case_aux c "S_Arrow"
  ].

Subtyping Examples and Exercises


Module Examples.

Notation x := (Id 0).
Notation y := (Id 1).
Notation z := (Id 2).

Notation A := (ty_base (Id 6)).
Notation B := (ty_base (Id 7)).
Notation C := (ty_base (Id 8)).

Notation String := (ty_base (Id 9)).
Notation Float := (ty_base (Id 10)).
Notation Integer := (ty_base (Id 11)).

Exercise: 2 stars, optional (subtyping judgements)

(Do this exercise after you have added product types to the language, at least up to this point in the file).
Using the encoding of records into pairs, define pair types representing the record types
    Person   := { name : String }
    Student  := { name : String ; 
                  gpa  : Float }
    Employee := { name : String ;
                  ssn  : Integer }
Definition Person : ty :=
(* FILL IN HERE *) admit.
Definition Student : ty :=
(* FILL IN HERE *) admit.
Definition Employee : ty :=
(* FILL IN HERE *) admit.

Example sub_student_person :
  subtype Student Person.
Proof.
(* FILL IN HERE *) Admitted.

Example sub_employee_person :
  subtype Employee Person.
Proof.
(* FILL IN HERE *) Admitted.

Example subtyping_example_0 :
  subtype (ty_arrow C Person)
          (ty_arrow C ty_Top).
(* C->Person <: C->Top *)
Proof.
  apply S_Arrow.
    apply S_Refl. auto.
Qed.

The following facts are mostly easy to prove in Coq. To get full benefit from the exercises, make sure you also understand how to prove them on paper!

Exercise: 1 star, optional (subtyping_example_1)

Example subtyping_example_1 :
  subtype (ty_arrow ty_Top Student)
          (ty_arrow (ty_arrow C C) Person).
(* Top->Student <: (C->C)->Person *)
Proof with eauto.
  (* FILL IN HERE *) Admitted.

Exercise: 1 star, optional (subtyping_example_2)

Example subtyping_example_2 :
  subtype (ty_arrow ty_Top Person)
          (ty_arrow Person ty_Top).
(* Top->Person <: Person->Top *)
Proof with eauto.
  (* FILL IN HERE *) Admitted.

End Examples.

Exercise: 1 star, 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. (Note that A, B, and C are base types.)
  • TS <: TS
  • TopU <: STop
  • (CC) (A*B) <: (CC) (Top*B)
  • TTU <: SSV
  • (TT)U <: (SS)V
  • ((TS)T)U <: ((ST)S)V
  • S*V <: T*U

Exercise: 1 star (subtype_instances_tf_2)

Which of the following statements are true? Write TRUE or FALSE after each one.
       S T,
          S <: T  
          SS   <:  TT

       S T,
           S <: AA 
            T,
              S = TT    T <: A

       S T1 T1,
           S <: T1  T2 
            S1 S2,
              S = S1  S2    T1 <: S1    S2 <: T2 

       S,
           S <: SS 

       S,
           SS <: S   

       S T2 T2,
           S <: T1*T2 
            S1 S2,
              S = S1*S2    S1 <: T1    S2 <: T2  

Exercise: 1 star (subtype_concepts_tf)

Which of the following statements are true, and which are false?
  • There exists a type that is a supertype of every other type.
  • There exists a type that is a subtype of every other type.
  • There exists a pair type that is a supertype of every other pair type.
  • There exists a pair type that is a subtype of every other pair type.
  • There exists an arrow type that is a supertype of every other arrow type.
  • There exists an arrow type that is a subtype of every other arrow type.
  • There is an infinite descending chain of distinct types in the subtype relation—-that is, an infinite sequence of types S0, S1, etc., such that all the Si's are different and each S(i+1) is a subtype of Si.
  • There is an infinite ascending chain of distinct types in the subtype relation—-that is, an infinite sequence of types S0, S1, etc., such that all the Si's are different and each S(i+1) is a supertype of Si.

Exercise: 2 stars (proper_subtypes)

Is the following statement true or false? Briefly explain your answer.
     T,
         ~( nT = ty_base n
          S,
            S <: T    S <> T

Exercise: 2 stars (small_large_1)

  • What is the smallest type T ("smallest" in the subtype relation) that makes the following assertion true?
      empty  (\p:T*Top. p.fst) ((\z:A.z), unit) : AA
  • What is the largest type T that makes the same assertion true?

Exercise: 2 stars (small_large_2)

  • What is the smallest type T that makes the following assertion true?
      empty  (\p:(AA * BB). p) ((\z:A.z), (\z:B.z)) : T
  • What is the largest type T that makes the same assertion true?

Exercise: 2 stars, optional (small_large_3)

  • What is the smallest type T that makes the following assertion true?
      a:A  (\p:(A*T). (p.snd) (p.fst)) (a , \z:A.z) : A
  • What is the largest type T that makes the same assertion true?

Exercise: 2 stars (small_large_4)

  • What is the smallest type T that makes the following assertion true?
       S,
        empty  (\p:(A*T). (p.snd) (p.fst)) : S
  • What is the largest type T that makes the same assertion true?

Exercise: 2 stars (smallest_1)

What is the smallest type T that makes the following assertion true?
       S t
        empty  (\x:T. x xt : S

Exercise: 2 stars (smallest_2)

What is the smallest type T that makes the following assertion true?
      empty  (\x:Top. x) ((\z:A.z) , (\z:B.z)) : T

Exercise: 3 stars, optional (count_supertypes)

How many supertypes does the record type {x:A, y:CC} have? That is, how many different types T are there such that {x:A, y:CC} <: T? (We consider two types to be different if they are written differently, even if each is a subtype of the other. For example, {x:A,y:B} and {y:B,x:A} are different.)

Typing

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

Definition context := id (option ty).
Definition empty : context := (fun _ => None).
Definition extend (Γ : context) (x:id) (T : ty) :=
  fun x' => if beq_id x x' then Some T else Γ x'.

Inductive has_type : context tm ty Prop :=
  (* Same as before *)
  | T_Var : Γ x T,
      Γ x = Some T
      has_type Γ (tm_var x) T
  | T_Abs : Γ x T11 T12 t12,
      has_type (extend Γ x T11) t12 T12
      has_type Γ (tm_abs x T11 t12) (ty_arrow T11 T12)
  | T_App : T1 T2 Γ t1 t2,
      has_type Γ t1 (ty_arrow T1 T2)
      has_type Γ t2 T1
      has_type Γ (tm_app t1 t2) T2
  | T_True : Γ,
       has_type Γ tm_true ty_Bool
  | T_False : Γ,
       has_type Γ tm_false ty_Bool
  | T_If : t1 t2 t3 T Γ,
       has_type Γ t1 ty_Bool
       has_type Γ t2 T
       has_type Γ t3 T
       has_type Γ (tm_if t1 t2 t3) T
  | T_Unit : Γ,
      has_type Γ tm_unit ty_Unit
  (* New rule of subsumption *)
  | T_Sub : Γ t S T,
      has_type Γ t S
      subtype S T
      has_type Γ t T.

Hint Constructors has_type.

Tactic Notation "has_type_cases" tactic(first) ident(c) :=
  first;
  [ Case_aux c "T_Var" | Case_aux c "T_Abs"
  | Case_aux c "T_App" | Case_aux c "T_True"
  | Case_aux c "T_False" | Case_aux c "T_If"
  | Case_aux c "T_Unit"
  | Case_aux c "T_Sub" ].

Typing examples


Module Examples2.
Import Examples.

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, optional (typing_example_0)

(* empty |- ((\z:A.z), (\z:B.z)) : (A->A * B->B) *)
(* FILL IN HERE *)

Exercise: 2 stars, optional (typing_example_1)

(* empty |- (\x:(Top * B->B). x.snd) ((\z:A.z), (\z:B.z)) : B->B *)
(* FILL IN HERE *)

Exercise: 2 stars, optional (typing_example_2)

(* empty |- (\z:(C->C)->(Top * B->B). (z (\x:C.x)).snd)
              (\z:C->C. ((\z:A.z), (\z:B.z)))
           : B->B *)

(* FILL IN HERE *)

End Examples2.

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, 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 record a couple of critical structural properties of the subtype relation:
  • Bool is the only subtype of Bool
  • every subtype of an arrow type is an arrow type.
These are called inversion lemmas because they play the same role in later 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 one 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, optional (sub_inversion_Bool)

Lemma sub_inversion_Bool : U,
     subtype U ty_Bool
       U = ty_Bool.
Proof with auto.
  intros U Hs.
  remember ty_Bool as V.
  (* FILL IN HERE *) Admitted.

Exercise: 3 stars, optional (sub_inversion_arrow)

Lemma sub_inversion_arrow : U V1 V2,
     subtype U (ty_arrow V1 V2)
      U1, U2,
       U = (ty_arrow U1 U2) (subtype V1 U1) (subtype U2 V2).
Proof with eauto.
  intros U V1 V2 Hs.
  remember (ty_arrow V1 V2) as V.
  generalize dependent V2. generalize dependent V1.
  (* FILL IN HERE *) Admitted.

Canonical Forms

We'll see first that the proof of the progress theorem doesn't change too much — we just need one small refinement. When we're considering the case where the term in question is an application t1 t2 where both t1 and t2 are values, we need to know that t1 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 t1 has a function type T11T12, 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 t1 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 Γ t1 : T11T12 is subsumption, then there is some sub-derivation whose subject is also t1, 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, optional (canonical_forms_of_arrow_types)

Lemma canonical_forms_of_arrow_types : Γ s T1 T2,
  has_type Γ s (ty_arrow T1 T2)
  value s
   x, S1, s2,
     s = tm_abs x S1 s2.
Proof with eauto.
  (* FILL IN HERE *) Admitted.
Similarly, the canonical forms of type Bool are the constants true and false.

Lemma canonical_forms_of_Bool : Γ s,
  has_type Γ s ty_Bool
  value s
  (s = tm_true s = tm_false).
Proof with eauto.
  intros Γ s Hty Hv.
  remember ty_Bool as T.
  has_type_cases (induction Hty) Case; try solve by inversion...
  Case "T_Sub".
    subst. apply sub_inversion_Bool in H. subst...
Qed.

Progress

The proof of progress proceeds 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, true, and false 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 t1 t2 and types T1 and T2 such that t = t1 t2, T = T2, empty t1 : T1 T2, and empty t2 : T1. Moreover, by the induction hypothesis, either t1 is a value or it steps, and either t2 is a value or it steps. There are three possibilities to consider:
    • Suppose t1 t1' for some term t1'. Then t1 t2 t1' t2 by ST_App1.
    • Suppose t1 is a value and t2 t2' for some term t2'. Then t1 t2 t1 t2' by rule ST_App2 because t1 is a value.
    • Finally, suppose t1 and t2 are both values. By Lemma canonical_forms_for_arrow_types, we know that t1 has the form \x:S1.s2 for some x, S1, and s2. But then (\x:S1.s2) t2 [t2/x]s2 by ST_AppAbs, since t2 is a value.
  • If the final step of the derivation uses rule T_If, then there are terms t1, t2, and t3 such that t = if t1 then t2 else t3, with empty t1 : Bool and with empty t2 : T and empty t3 : T. Moreover, by the induction hypothesis, either t1 is a value or it steps.
    • If t1 is a value, then by the canonical forms lemma for booleans, either t1 = true or t1 = false. In either case, t can step, using rule ST_IfTrue or ST_IfFalse.
    • If t1 can step, then so can t, by rule ST_If.
  • 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.

Theorem progress : t T,
     has_type empty t T
     value t t', t t'.
Proof with eauto.
  intros t T Ht.
  remember empty as Γ.
  revert HeqGamma.
  has_type_cases (induction Ht) Case;
    intros HeqGamma; subst...
  Case "T_Var".
    inversion H.
  Case "T_App".
    right.
    destruct IHHt1; subst...
    SCase "t1 is a value".
      destruct IHHt2; subst...
      SSCase "t2 is a value".
        destruct (canonical_forms_of_arrow_types empty t1 T1 T2)
          as [x [S1 [t12 Heqt1]]]...
        subst. (subst t2 x t12)...
      SSCase "t2 steps".
        destruct H0 as [t2' Hstp]. (tm_app t1 t2')...
    SCase "t1 steps".
      destruct H as [t1' Hstp]. (tm_app t1' t2)...
  Case "T_If".
    right.
    destruct IHHt1.
    SCase "t1 is a value"...
      assert (t1 = tm_true t1 = tm_false)
        by (eapply canonical_forms_of_Bool; eauto).
      inversion H0; subst...
      destruct H. rename x into t1'. eauto.

Qed.

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 "obvious from the definition" in the pure STLC (and hence 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 Γ \x:S1.t2 : T whose subject is an abstraction, then there must be some subderivation giving a type to the body t2.
Lemma: If Γ \x:S1.t2 : T, then there is a type S2 such that Γ, x:S1 t2 : S2 and S1 S2 <: T.
(Notice that the lemma does not say, "then T itself is an arrow type" — this is tempting, but false!)
Proof: Let Γ, x, S1, t2 and T be given as described. Proceed by induction on the derivation of Γ \x:S1.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 T12 such that T = S1 T12 and Γ, x:S1 t2 : T12. Picking T12 for S2 gives us what we need: S1 T12 <: S1 T12 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 Γ \x:S1.t2 : S. The IH for the typing subderivation tell us that there is some type S2 with S1 S2 <: S and Γ, x:S1 t2 : S2. Picking type S2 gives us what we need, since S1 S2 <: T then follows by S_Trans.

Lemma typing_inversion_abs : Γ x S1 t2 T,
     has_type Γ (tm_abs x S1 t2) T
     ( S2, subtype (ty_arrow S1 S2) T
               has_type (extend Γ x S1) t2 S2).
Proof with eauto.
  intros Γ x S1 t2 T H.
  remember (tm_abs x S1 t2) as t.
  has_type_cases (induction H) Case;
    inversion Heqt; subst; intros; try solve by inversion.
  Case "T_Abs".
     T12...
  Case "T_Sub".
    destruct IHhas_type as [S2 [Hsub Hty]]...
  Qed.

Similarly...

Lemma typing_inversion_var : Γ x T,
  has_type Γ (tm_var x) T
   S,
    Γ x = Some S subtype S T.
Proof with eauto.
  intros Γ x T Hty.
  remember (tm_var x) as t.
  has_type_cases (induction Hty) Case; intros;
    inversion Heqt; subst; try solve by inversion.
  Case "T_Var".
     T...
  Case "T_Sub".
    destruct IHHty as [U [Hctx HsubU]]... Qed.

Lemma typing_inversion_app : Γ t1 t2 T2,
  has_type Γ (tm_app t1 t2) T2
   T1,
    has_type Γ t1 (ty_arrow T1 T2)
    has_type Γ t2 T1.
Proof with eauto.
  intros Γ t1 t2 T2 Hty.
  remember (tm_app t1 t2) as t.
  has_type_cases (induction Hty) Case; intros;
    inversion Heqt; subst; try solve by inversion.
  Case "T_App".
     T1...
  Case "T_Sub".
    destruct IHHty as [U1 [Hty1 Hty2]]...
Qed.

Lemma typing_inversion_true : Γ T,
  has_type Γ tm_true T
  subtype ty_Bool T.
Proof with eauto.
  intros Γ T Htyp. remember tm_true as tu.
  has_type_cases (induction Htyp) Case;
    inversion Heqtu; subst; intros...
Qed.

Lemma typing_inversion_false : Γ T,
  has_type Γ tm_false T
  subtype ty_Bool T.
Proof with eauto.
  intros Γ T Htyp. remember tm_false as tu.
  has_type_cases (induction Htyp) Case;
    inversion Heqtu; subst; intros...
Qed.

Lemma typing_inversion_if : Γ t1 t2 t3 T,
  has_type Γ (tm_if t1 t2 t3) T
  has_type Γ t1 ty_Bool
   has_type Γ t2 T
   has_type Γ t3 T.
Proof with eauto.
  intros Γ t1 t2 t3 T Hty.
  remember (tm_if t1 t2 t3) as t.
  has_type_cases (induction Hty) Case; intros;
    inversion Heqt; subst; try solve by inversion.
  Case "T_If".
    auto.
  Case "T_Sub".
    destruct (IHHty H0) as [H1 [H2 H3]]...
Qed.

Lemma typing_inversion_unit : Γ T,
  has_type Γ tm_unit T
    subtype ty_Unit T.
Proof with eauto.
  intros Γ T Htyp. remember tm_unit as tu.
  has_type_cases (induction Htyp) Case;
    inversion Heqtu; subst; intros...
Qed.

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.

Lemma abs_arrow : x S1 s2 T1 T2,
  has_type empty (tm_abs x S1 s2) (ty_arrow T1 T2)
     subtype T1 S1
   has_type (extend empty x S1) s2 T2.
Proof with eauto.
  intros x S1 s2 T1 T2 Hty.
  apply typing_inversion_abs in Hty.
  destruct Hty as [S2 [Hsub Hty]].
  apply sub_inversion_arrow in Hsub.
  destruct Hsub as [U1 [U2 [Heq [Hsub1 Hsub2]]]].
  inversion Heq; subst... Qed.

Context Invariance

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

Inductive appears_free_in : id tm Prop :=
  | afi_var : x,
      appears_free_in x (tm_var x)
  | afi_app1 : x t1 t2,
      appears_free_in x t1 appears_free_in x (tm_app t1 t2)
  | afi_app2 : x t1 t2,
      appears_free_in x t2 appears_free_in x (tm_app t1 t2)
  | afi_abs : x y T11 t12,
        y <> x
        appears_free_in x t12
        appears_free_in x (tm_abs y T11 t12)
  | afi_if1 : x t1 t2 t3,
      appears_free_in x t1
      appears_free_in x (tm_if t1 t2 t3)
  | afi_if2 : x t1 t2 t3,
      appears_free_in x t2
      appears_free_in x (tm_if t1 t2 t3)
  | afi_if3 : x t1 t2 t3,
      appears_free_in x t3
      appears_free_in x (tm_if t1 t2 t3)
.

Hint Constructors appears_free_in.

Lemma context_invariance : Γ Gamma' t S,
     has_type Γ t S
     ( x, appears_free_in x t Γ x = Gamma' x)
     has_type Gamma' t S.
Proof with eauto.
  intros. generalize dependent Gamma'.
  has_type_cases (induction H) Case;
    intros Gamma' Heqv...
  Case "T_Var".
    apply T_Var... rewrite Heqv...
  Case "T_Abs".
    apply T_Abs... apply IHhas_type. intros x0 Hafi.
    unfold extend. remember (beq_id x x0) as e.
    destruct e...
  Case "T_App".
    apply T_App with T1...
  Case "T_If".
    apply T_If...

Qed.

Lemma free_in_context : x t T Γ,
   appears_free_in x t
   has_type Γ t T
    T', Γ x = Some T'.
Proof with eauto.
  intros x t T Γ Hafi Htyp.
  has_type_cases (induction Htyp) Case;
      subst; inversion Hafi; subst...
  Case "T_Abs".
    destruct (IHHtyp H4) as [T Hctx]. T.
    unfold extend in Hctx. apply not_eq_beq_id_false in H2.
    rewrite H2 in Hctx... Qed.

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 use the inversion lemmas that we proved above to extract structural information from assumptions about the well-typedness of subterms.

Lemma substitution_preserves_typing : Γ x U v t S,
     has_type (extend Γ x U) t S
     has_type empty v U
     has_type Γ (subst v x t) S.
Proof with eauto.
  intros Γ x U v t S Htypt Htypv.
  generalize dependent S. generalize dependent Γ.
  tm_cases (induction t) Case; intros; simpl.
  Case "tm_var".
    rename i into y.
    destruct (typing_inversion_var _ _ _ Htypt)
        as [T [Hctx Hsub]].
    unfold extend in Hctx.
    remember (beq_id x y) as e. destruct e...
    SCase "x=y".
      apply beq_id_eq in Heqe. subst.
      inversion Hctx; subst. clear Hctx.
      apply context_invariance with empty...
      intros x Hcontra.
      destruct (free_in_context _ _ S empty Hcontra)
          as [T' HT']...
      inversion HT'.
  Case "tm_app".
    destruct (typing_inversion_app _ _ _ _ Htypt)
        as [T1 [Htypt1 Htypt2]].
    eapply T_App...
  Case "tm_abs".
    rename i into y. rename t into T1.
    destruct (typing_inversion_abs _ _ _ _ _ Htypt)
      as [T2 [Hsub Htypt2]].
    apply T_Sub with (ty_arrow T1 T2)... apply T_Abs...
    remember (beq_id x y) as e. destruct e.
    SCase "x=y".
      eapply context_invariance...
      apply beq_id_eq in Heqe. subst.
      intros x Hafi. unfold extend.
      destruct (beq_id y x)...
    SCase "x<>y".
      apply IHt. eapply context_invariance...
      intros z Hafi. unfold extend.
      remember (beq_id y z) as e0. destruct e0...
      apply beq_id_eq in Heqe0. subst.
      rewrite Heqe...
  Case "tm_true".
      assert (subtype ty_Bool S)
        by apply (typing_inversion_true _ _ Htypt)...
  Case "tm_false".
      assert (subtype ty_Bool S)
        by apply (typing_inversion_false _ _ Htypt)...
  Case "tm_if".
    assert (has_type (extend Γ x U) t1 ty_Bool
             has_type (extend Γ x U) t2 S
             has_type (extend Γ x U) t3 S)
      by apply (typing_inversion_if _ _ _ _ _ Htypt).
    destruct H as [H1 [H2 H3]].
    apply IHt1 in H1. apply IHt2 in H2. apply IHt3 in H3.
    auto.
  Case "tm_unit".
    assert (subtype ty_Unit S)
      by apply (typing_inversion_unit _ _ Htypt)...
Qed.

Preservation

The proof of preservation now proceeds pretty much as in earlier chapters, using the substitution lemma at the appropriate point and again using inversion lemmas from above to extract structural information from typing assumptions.
Theorem (Preservation): If t, t' are terms and T is a type such that empty t : T and t t', then empty t' : T.
Proof: Let t and T be given such that empty t : T. We go by induction on the structure of this typing derivation, leaving t' general. The cases T_Abs, T_Unit, T_True, and T_False cases are vacuous because abstractions and constants don't step. Case T_Var is vacuous as well, since the context is empty.
  • If the final step of the derivation is by T_App, then there are terms t1 t2 and types T1 T2 such that t = t1 t2, T = T2, empty t1 : T1 T2 and empty t2 : T1.
    By inspection of the definition of the step relation, there are three ways t1 t2 can step. Cases ST_App1 and ST_App2 follow immediately by the induction hypotheses for the typing subderivations and a use of T_App.
    Suppose instead t1 t2 steps by ST_AppAbs. Then t1 = \x:S.t12 for some type S and term t12, and t' = [t2/x]t12.
    By lemma abs_arrow, we have T1 <: S and x:S1 s2 : T2. It then follows by the substitution lemma (substitution_preserves_typing) that empty [t2/x] t12 : T2 as desired.
    • If the final step of the derivation uses rule T_If, then there are terms t1, t2, and t3 such that t = if t1 then t2 else t3, with empty t1 : Bool and with empty t2 : T and empty t3 : T. Moreover, by the induction hypothesis, if t1 steps to t1' then empty t1' : Bool. There are three cases to consider, depending on which rule was used to show t t'.
      • If t t' by rule ST_If, then t' = if t1' then t2 else t3 with t1 t1'. By the induction hypothesis, empty t1' : Bool, and so empty t' : T by T_If.
      • If t t' by rule ST_IfTrue or ST_IfFalse, then either t' = t2 or t' = t3, and empty t' : T follows by assumption.
  • 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 result is immediate by the induction hypothesis for the typing subderivation and an application of T_Sub.

Theorem preservation : t t' T,
     has_type empty t T
     t t'
     has_type empty t' T.
Proof with eauto.
  intros t t' T HT.
  remember empty as Γ. generalize dependent HeqGamma.
  generalize dependent t'.
  has_type_cases (induction HT) Case;
    intros t' HeqGamma HE; subst; inversion HE; subst...
  Case "T_App".
    inversion HE; subst...
    SCase "ST_AppAbs".
      destruct (abs_arrow _ _ _ _ _ HT1) as [HA1 HA2].
      apply substitution_preserves_typing with T...
Qed.

Exercises on Typing

Exercise: 2 stars (variations)

Each part of this problem suggests a different way of changing the definition of the STLC with Unit and subtyping. (These changes are not cumulative: each part starts from the original language.) In each part, list which properties (Progress, Preservation, both, or neither) become false. If a property becomes false, give a counterexample.
  • Suppose we add the following typing rule:
    Γ  t : S1->S2
    S1 <: T1      T1 <: S1     S2 <: T2 (T_Funny1)  

    Γ  t : T1->T2
  • Suppose we add the following reduction rule:
       (ST_Funny21)  

    unit  (\x:Top. x)
  • Suppose we add the following subtyping rule:
       (S_Funny3)  

    Unit <: Top->Top
  • Suppose we add the following subtyping rule:
       (S_Funny4)  

    Top->Top <: Unit
  • Suppose we add the following evaluation rule:
       (ST_Funny5)  

    (unit t)  (t unit)
  • Suppose we add the same evaluation rule and a new typing rule:
       (ST_Funny5)  

    (unit t)  (t unit)
       (T_Funny6)  

    empty  Unit : Top->Top
  • Suppose we change the arrow subtyping rule to:
    S1 <: T1       S2 <: T2 (S_Arrow')  

    S1->S2 <: T1->T2

Exercise: Adding Products

Exercise: 4 stars, optional (products)

Adding pairs, projections, and product types to the system we have defined is a relatively straightforward matter. Carry out this extension:
  • Add constructors for pairs, first and second projections, and product types to the definitions of ty and tm. (Don't forget to add corresponding cases to ty_cases and tm_cases.)
  • Extend the well-formedness relation in the obvious way.
  • Extend the operational semantics with the same reduction rules as in the last chapter.
  • Extend the subtyping relation with this rule:
    S1 <: T1     S2 <: T2 (Sub_Prod)  

    S1 * S2 <: T1 * T2
  • Extend the typing relation with the same rules for pairs and projections as in the last chapter.
  • Extend the proofs of progress, preservation, and all their supporting lemmas to deal with the new constructs. (You'll also need to add some completely new lemmas.)