Simple Extensions to STLC

let-bindings

When writing a complex expression, it is often useful---both for avoiding repetition and for increasing readability---to give names to some of its subexpressions. Most languages provide one or more ways of doing this. In OCaml, for example, we can write let x=t1 in t2 to mean ``evaluate the expression t1 and bind the name x to the resulting value while evaluating t2.'' Our let-binder follows ML's in choosing a call-by-value evaluation order, where the let-bound term must be fully evaluated before evaluation of the let-body can begin. The typing rule T_Let tells us that the type of a let can be calculated by calculating the type of the let-bound term, extending the context with a binding with this type, and in this enriched context calculating the type of the body, which is then the type of the whole let expression. At this point in the course, it's probably just as easy to simply look at the rules defining this new feature as to wade through a lot of english text conveying the same information. Here they are: Syntax:

       t ::=                Terms:
           | x                 variable
           | \x:T. t           abstraction
           | t t               application
           | let x=t in t      let-binding

Reduction:

t1 --> t1'	(ST_Let1)
let x=t1 in t2 --> let x=t1' in t2

	(ST_LetValue)
let x=v1 in t2 --> [v1/x] t2

Typing:

Gamma |- t1 : T1      Gamma, x:T1 |- t2 : T2	(T_Let)
Gamma |- let x=t1 in t2 : T2

Pairs

Our functional programming examples have made frequent use of pairs of values. The type of such pairs is called a product type. In Coq's functional language, the primitive way of extracting the components of a pair is pattern matching. An alternative style is to take fst and snd -- the first- and second-projection operators -- as primitives. Just for fun (and for compatibility with the way we're going to do records just below), let's do our products this way. Syntax:

       t ::=                Terms:
           | ...
           | (t,t)             pair
           | t.fst             first projection
           | t.snd             second projection

       v ::=                Values:
           | \x:T.t
           | (v,v)             pair value

       T ::=                Types:
           | A                 base type
           | T -> T            arrow type
           | T * T             product type

Reduction:

t1 --> t1'	(ST_Pair1)
(t1,t2) --> (t1',t2)

t2 --> t2'	(ST_Pair2)
(v1,t2) --> (v1,t2')

t1 --> t1'	(ST_Fst1)
t1.fst --> t1'.fst

	(ST_FstPair)
(v1,v2).fst --> v1

t1 --> t1'	(ST_Snd1)
t1.snd --> t1'.snd

	(ST_SndPair)
(v1,v2).snd --> v2

(Note the implicit convention that metavariables like v1 always denote values.) Typing:

Gamma |- t1 : T1       Gamma |- t2 : T2	(T_Pair)
Gamma |- (t1,t2) : T1*T2

Gamma |- t1 : T1*T2	(T_Fst)
Gamma |- t1.fst : T1

Gamma |- t1 : T1*T2	(T_Snd)
Gamma |- t1.snd : T2

Next, let's look at the generalization of products to records -- n-ary products with labeled fields. Syntax:

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

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

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

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

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

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

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

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

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

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

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. Below we give the syntax, semantics, and typing rules for lists. Except for the fact that explicit type annotations are mandatory on nil and cannot appear on cons, these lists are essentially identical to those we defined in Coq. We use case (a very simplified form of match) to destruct lists, to avoid dealing with questions like "what is the head of the empty list?" While we say that cons v1 v2 is a value, we only mean that when v2 is also a list -- we'll have to enforce this in the formal definition of value. Syntax:

       t ::=                Terms:
           | nil T
           | cons t t
           | case t of 
                 nil -> t
               | x::x -> t

       v ::=                Values:
           | ...
           | nil T             nil value
           | cons v v          cons value

       T ::=                Types:
           | list T
           | ...

Reduction:

t1 --> t1'	(ST_Cons1)
cons t1 t2 --> cons t1' t2

t2 --> t2'	(ST_Cons2)
cons v1 t2 --> cons v1 t2'

t1 --> t1                          (ST_Case1)
(case t1 of nil -> t2 | h::t -> t3) --> (case t1' of nil -> t2 | h::t -> t3)

	(ST_CaseNil)
(case nil T of nil -> t2 | h::t -> t3) --> t2

(ST_CaseCons)
(case (cons vh vt) of nil -> t2 | h::t -> t3) --> [vh/h,vt/t]t3

Typing:

	(T_Nil)
Gamma |- nil T : list T

Gamma |- t1 : T      Gamma |- t2 : list T	(T_Cons)
Gamma |- cons t1 t2: list T

Gamma |- t1 : list T1        Gamma |- t2 : T
Gamma, h:T1, t:list T1 |- t3 : T	(T_Case)
Gamma |- (case t1 of nil -> t2 | h::t -> t3) : T

General recursion

Another facility found in most programming languages (including Coq) is the ability to define recursive functions. For example, we might like to be able to define the factorial function like this:

   fact = \x:nat. 
             if x=0 then 1 else x * (fact (pred x)))    

But this would be require quite a bit of work to formalize: we'd have to introduce a notion of "function definitions" and carry around an "environment" of such definitions in the definition of the step relation. Here is another way that is straightforward to formalize: instead of writing recursive definitions where the right-hand side can contain the identifier being defined, we can define a fixed-point operator that performs the "unfolding" of the recursive definition in the right-hand side lazily during reduction.

   fact = 
       fix
         (\f:nat->nat.
            \x:nat. 
               if x=0 then 1 else x * (f (pred x)))    

The intuition is that the higher-order function f passed to fix is a generator for the fact function: if f is applied to a function that approximates the desired behavior of fact 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 fact---a function that returns correct results for inputs up to n+1. Applying fix to this generator returns its fixed point---a function that gives the desired behavior for all inputs n. Syntax:

       t ::=                Terms:
           | ...
           | fix t             fixed-point operator

Reduction:

t1 --> t1'	(ST_Fix1)
fix t1 --> fix t1'

	(ST_FixAbs)
fix (\x:T1.t2) --> [(fix(\x:T1.t2)) / x] t2

Typing:

Gamma |- t1 : T1->T1	(T_Fix)
Gamma |- fix t1 : T1

Exercise: 1 star (halve_fix)

Translate this recursive definition into one using fix:

   halve = 
     \x:nat. 
        if x=0 then 0 
        else if (pred x)=0 then 0
        else 1 + (halve (pred (pred x))))

(* FILL IN HERE *)
☐

Exercise: 1 star (fact_steps)

Write down the sequence of steps that the term fact 1 goes through to reduce to a normal form (assuming the usual reduction rules for arithmetic operations). (* FILL IN HERE *)
☐

Formalizing the extensions

Exercise: 5 stars (STLC_extensions)

The rest of the file formalizes just the most interesting extension, records. Formalizing the others is left to you. We've provided the necessary extensions to the syntax of terms and types, and we've included a few examples that you can test your definitions with to make sure they are working as expected. You'll fill in the rest of the definitions and extend all the proofs accordingly. (A good strategy is to work on the extensions one at a time, in multiple passes, rather than trying to work through the file from start to finish in a single pass.)

Syntax and operational semantics

The most obvious way to formalize the syntax of record types would be this:

Unfortunately, we encounter here a limitation in Coq: this type does not automatically give us the induction principle we expect the induction hypothesis in the ty_rcd case doesn't give us any information about the ty elements of the list, making it useless for the proofs we want to do.

It is possible to get a better induction principle out of Coq, but the details of how this is done are not very pretty, and it is not as intuitive to use as the ones Coq generates automatically for simple Inductive definitions. Fortunately, there is a different way of formalizing records that is, in some ways, even simpler and more natural: instead of using the existing list type, we can essentially include its constructors ("nil" and "cons") in the syntax of types. (Since this is the final definition that we'll use for the rest of the chapter, we also include constructors for and pairs lists and a base type of numbers.)

Similarly, at the level of terms, we have constructors tm_rnil the empty record -- and tm_rcons, which adds a single field to the front of a list of fields.

Some variables, for examples...

{ i1:A }

{ i1:A->B, i2:A }

Well-formedness

Generalizing our abstract syntax for records (from lists to the nil/cons presentation) introduces the possibility of writing strange types like this:

where the "tail" of a record type is not actually a record type! We'll structure our typing judgement so that no ill-formed types like weird_type are assigned to terms. To support this, we define record_ty and record_tm, which identify record types and terms, and well_formed_ty which rules out the ill-formed types. First, a type is a record type if it is built with either ty_rnil or ty_rcons.

Similarly, a term is a record term if it is built with tm_rnil or tm_rcons

Note that record_ty and record_tm are not recursive -- they just checkw the outermost constructor. The well_formed_ty property, on the other hand, verifies that the whole type is well formed in the sense that the tail of every record (the second argument to ty_rcons) is a record. Of course, we should also be concerned about ill-formed terms, but typechecking can rules those out without the help of an extra well_formed_tm definition because it already examines the structure of terms. LATER : should they fill in part of this as an exercise? We didn't give rules for it above

Substitution

Reduction

Next we define the valuesof our language. A record is a value if all of its fields are.

Utility functions for extracting one field from record type or term

The step function uses the term-level lookup function (for the projection rule), while the type-level lookup is needed for has_type.

Typing

Next we define the typing rules. These are nearly direct transcriptions of the inference rules shown above. The only major difference is the use of well_formed_ty. In the informal presentation we used a grammar that only allowed well formed record types, so we didn't have to add a separate check. We'd like to set things up so that that whenever has_type Gamma t T holds, we also have well_formed_ty T. That is, has_type never assigns ill-formed types to terms. In fact, we prove this theorem below. However, we don't want to clutter the definition of has_type with unnecessary uses of well_formed_ty. Instead, we place well_formed_ty checks only where needed - where an inductive call to has_type won't already be checking the well-formedness of a type. For example, we check well_formed_ty T in the T_Var case, because there is no inductive has_type call that would enforce this. Similarly, in the T_Abs case, we require a proof of well_formed_ty T11 because the inductive call to has_type only guarantees that T12 is well-formed. In the rules you must write, the only necessary well_formed_ty check comes in the tm_nil case.

Examples

Exercise: 2 stars (examples)

Finish the proofs.

  fact := 
       fix
         (\f:nat->nat.
            \a:nat. 
               if a=0 then 1 else a * (f (pred a)))

Note that you may be able to type check fact but still have some rules wrong!

☐

Feel free to use Coq's automation features in this proof. However, if you are not confident about how the type system works, you may want to carry out the proof first using the basic features (apply instead of eapply, in particular) and then perhaps compress it using automation.

Before starting to prove this fact (or the one above!), make sure you understand what it is saying.

Properties of typing

The proofs of progress and preservation for this system are essentially the same (though of course somewhat longer!) as for the pure simply typed lambda-calculus. The main change is the addition of some technical lemmas involving records.

Well-formedness

Field lookup

Here is an informal proof of the theorem below. Lemma: If empty |- v : T and ty_lookup i T returns Some Ti, then tm_lookup i v returns Some ti for some term ti such that has_type empty ti Ti. Proof: By induction on the typing derivation Htyp. Since ty_lookup i T = Some Ti, T must be a record type, this and the fact that v is a value eliminate most cases by inspection, leaving only the T_RCons case. If the last step in the typing derivation is by T_RCons, then t = tm_rcons i0 t tr and T = ty_rcons i0 T Tr for some i0, t, tr, T and Tr. This leaves two possiblities to consider - either i0 = i or not.

• If i = i0, then since ty_lookup i (ty_rcons i0 T Tr) = Some Ti we have T = Ti. It follows that t itself satisfies the theorem.
• On the other hand, suppose i <> i0. Then
          ty_lookup i T = ty_lookup i Tr
  and
          tm_lookup i t = tm_lookup i tr,
  so the result follows from the induction hypothesis. ☐

Progress

Context invariance

Preservation

☐

Subtyping: Subtyping

Subtyping

A motivating example

In the simply typed lamdba-calculus with records from the last chapter, 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 -- to functions, pairs, etc.

Subtyping and object-oriented languages

The principle of subtyping plays a fundamental role in many present-day 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 subinterface) can be used in place of one from a superclass (/superinterface) provides a degree of flexibility that is is extremely handy for organizing complex libraries. For example, a graphical user interface toolkit like Java's AWT 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, we won't deal with any of these issues, and we won't even talk any more about objects or classes. (There is a lot of discussion in Types and Programming Languages, for those that are interested.) Instead, we'll study the "essential core" of the subclass / subinterface relation in the stripped down setting of the STLC.

The subsumption rule

Our goal for this chapter is to add subtyping to the simply typed lambda-calculus with records. This involves two steps:

• Defining subtyping as a binary 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 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: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 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. To begin with, we need to formalize the basic intuition about record types that a longer record should be a subtype of a shorter one.

for each jk in j1..jn, exists ip in i1..im with 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. For example:

       {x:nat,y:bool} <: {x:nat}             "width subtyping"
       {x:nat} <: {}
       {x:nat,y:bool} <: {y:bool,x:nat}      "permutation"
       {x:nat,y:bool} <: {y:bool}
       {a:{x:nat}} <: {a:{}}                 "depth subtyping"

Formally, our record types are presented in a "binary" form (with constructors for nil and cons, rather than a single constructor that assembles a whole multi-field record all at once), and so we'll need to formulate subtyping in the same way. This can be accomplished by replacing the single rule above with a combination of three rules. To state these rules, we need to begin by introducing informal notations corresponding to the constructors ty_rnil and ty_rcons. We'll write ty_rnil as {} (just like we have been), and we'll write ty_rcons k S T as k:S;T (note the semicolon). So, for example, a record with three fields might be written j:A;k:B;l:C;{}. However, since looks a bit awkward and nonstandard, we'll introduce one final informal convention: in multi-field record types like this expression, we'll pick up the left curly brace and move it all the way to the left of the expression, changing the semicolons to commas as we go. In other words the informal expressions

     j:A;k:B;l:C;{}

and

     {j:A,k:B,l:C}

will mean the very same thing -- they will both denote this formal record type:

     ty_rcons j (ty_base A) 
        (ty_rcons k (ty_base B) 
           (ty_rcons l (ty_base C) 
              ty_rnil))

With these notations in hand, we're ready to talk about the three subtyping rules for records. First, any record type is a subtype of the empty record type:

	(S_RcdWidth)
Tr <: {}

Second, we can apply subtyping inside the components of a compound record type:

S1 <: T1       Sr2 <: Tr2	(S_RcdDepth)
i1:S1; Sr2 <: i1:T1; Tr2

We can use S_RcdDepth and S_RcdWidth together to drop later fields of a multi-field record while keeping earlier fields, showing for example that {y:B->B, x:A->A} <: {y:B->B}. We can also use S_RcdDepth and S_RcdWidth together to show that {y:{z:B->B}, x:A->A} <: {y:{}}. The example we originally had in mind was {x:A->A,y:B->B} <: {y:B->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. To handle the original example, we also need to be able to reorder fields:

i1 <> i2	(S_RcdPerm)
i1:T1; i2:T2; Tr3 <: i2:T2; i1:T1; Tr3

For example, {x:A->A,y:B->B} <: {y:B->B,x:A->A}. We can also include a general 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

This rule allows us to paste together the proofs we've seen that {x:A->A, y:B->B} <: {y:B->B, x:A->A} (by S_RcdPerm) and that {y:B->B, x:A->A} <: {y:B->B} (by S_RcdDepth and S_RcdWidth), to yield a proof that {x:A->A, y:B->B} <: {y:B->B}. This completes the subtyping rules for records. To finish the whole definition of subtyping, we need to consider how each of the other type constructors behaves with respect to subtyping. Since we're dealing with a very simple language with just arrows and records, we have only arrows left to deal with. A variant of the first example motivates the discussion. Suppose we have two functions f and g with these types:

       f  :  C -> {x:A->A,y:B->B}
       g  :  (C->{y:B->B}) -> D

That is, f is a function that yields a record of type {x:A->A,y:B->B}, and g is a higher-order function that expects its (function) argument to yield a record of type {y:B->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_Arrow)
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 S1->S2 to be a subtype of T1->T2, 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 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. Finally, we add one last structural rule, which (together with transitivity) ensures that the subtype relation is a preorder:

	(S_Refl)
T <: T

We can stop here, if we like. But it is common practice to go one further step and add 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#. Some more examples:

• {}->{j:A} <: {k:B}->Top
• Top->{k:A->A,j:B->B} <: (C->C)->{j:B->B}

Variations

Real languages often 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 ("multiple inheritance" of interfaces)
  • i.e., permutation is allowed for interfaces.

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; in particular, we'll add "well formedness" properties for both terms and types that verify that the record constructors are properly used. 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

Well-formedness

First, a type is a record type if it is built with either ty_rnil or ty_rcons. Similarly, a term is a record term if it is built with either tm_rnil or tm_rcons

Note that record_ty is not recursive -- it just checks the outermost constructor. The well_formed_ty property, on the other hand, verifies that the whole type is well formed in the sense that the tail of every record (the second argument to ty_rcons) is a record.

Substitution

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

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.

Definition

The definition of subtyping is essentially just what we sketched in the motivating discussion, but we need to add well-formedness side conditions to some of the rules.

Subtyping examples and exercises

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: 2 stars

☐

Exercise: 1 star

☐

Exercise: 1 star

☐

Exercise: 2 stars

☐

Exercise: 1 star (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.

• T->S <: T->S
• Top->U <: S->Top
• (C->C)->{x:A->A,y:B->B} <: (C->C)->{y:B->B}
• ty_rnil -> ty_rnil <: {x:A} -> Top
• T->T->U <: S->S->V
• (T->T)->U <: (S->S)->V
• ((T->S)->T)->U <: ((S->T)->S)->V
• {a:S, b:V} <: {a:T, b:U}

☐

Exercise: 1 star (subtype_instances_tf_2)

Which of the following statements are true? Write TRUE or FALSE after each one.

•       forall S T,
            S <: T ->
            S->S <: T->T
•       forall S T,
             S <: A->A ->
             exists T,
                S = T->T /\ T <: A
•       forall S T1 T1,
             S <: T1 -> T2 ->
             exists S1 S2,
                S = S1 -> S2 /\ T1 <: S1 /\ S2 <: T2
•       exists S,
             S <: S->S
•       exists S,
             S->S <: S
•       forall S T2 T2,
             S <: {j:T1,k:T2} ->
             exists S1 S2,
                S = {j:S1,k: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 record type that is a subtype of every other record type.
• There exists a record type that is a supertype of every other record type.
• There exists an arrow type that is a subtype of every other arrow type.
• There exists an arrow type that is a supertype 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: 1 star (proper_subtypes)

Is the following statement true or false? Briefly explain your answer. ☐

Exercise: 1 star (small_large_1)

• What is the smallest type T ("smallest" in the subtype relation) that makes the following assertion true?
         empty |- (\r:{x:T}. r.x) {x=(\z:A.z)} : A->A
• What is the largest type T that makes the same assertion true?

☐

Exercise: 1 star (small_large_2)

• What is the smallest type T that makes the following assertion true?
         empty |- (\r:{y:B->B, x:A->A}. r) {x=(\z:A.z), y=(\z:B.z)} : T
• What is the largest type T that makes the same assertion true?

☐

Exercise: 1 star (small_large_3)

• What is the smallest record type T that makes the following assertion true?
         a:A |- (\r:(x:A;T)}. (r.y) (r.x)) {y=(\z:A.z), x=a} : A
• What is the largest record type T that makes the same assertion true?

☐

Exercise: 1 star (small_large_4)

• What is the smallest record type T that makes the following assertion true?
         exists S,
           empty |- (\r:(x:A;T). (r.y) (r.x)) : S
• What is the largest record type T that makes the same assertion true?

☐

Exercise: 1 star (smallest_1)

What is the smallest type T that makes the following assertion true? ☐

Exercise: 1 star (smallest_2)

What is the smallest type T that makes the following assertion true? ☐

Exercise: 1 star (count_supertypes)

How many supertypes does the type {x:A, y:C->C} have? That is, how many different types T are there such that {x:A, y:C->C} <: 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.) ☐

Properties of subtyping

Well-formedness

Exercise: 1 star (wf_variation)

The proof of the subtype__wf lemma goes by induction on the derivation of S <: T. Suppose we change the statement of the lemma to and again start the proof by induction on the derivation of S <: T. Will we succeed in completing it? Briefly explain. ☐

Field lookup

Our record matching lemmas get a little more complicated in the presence of subtyping for two reasons: First, record types no longer necessarily describe the exact structure of corresponding terms. Second, reasoning by induction on has_type derivations becomes harder in general, because has_type is no longer syntax directed.

Exercise: 3 stars (rcd_types_match_informal)

Write a careful informal proof of the rcd_types_match lemma.

☐

Inversion lemmas

Exercise: 3 stars (sub_inversion_arrow)

☐

Typing

Again, the typing relation is exactly the same, except for (a) the rule of subsumption, T_Sub, and (b) some well-formedness side conditions.

Typing examples

Exercise: 1 star

☐

Exercise: 2 stars

☐

Exercise: 2 stars, optional

☐

Properties of typing

Well-formedness

Field lookup