CS611 Lecture 31 Subtype Polymorphism 20 November 2006Lecturer: Dexter Kozen1 IntroductionIn this lecture, we attempt to extend the typed λ-calculus to support objects. In particular, we explore theconcept of subtyping in detail, which is one of the key features of object-oriented languages.Subtyping was first introduced in Simula, the first object-oriented programming language. Its inventorsOle-Johan Dahl and Kristen Nygaard later went on to win the Turing award for their contribution to thefield of objec t-oriented programming. Simula introduced a number of innovative features that have becomethe mainstay of modern OO languages including objects, subtyping and inheritance.The concept of subtyping is closely tied to inheritance and polymorphism and offers a formal way ofstudying them. It is best illustrated by means of an example.RATAGraduateUndergradStudent StaffPersoncccccccccccc############Figure 1: A Subtype HierarchyThis is an example of a hierarchy that describes a subtype relationship between different types. In thiscase, the types Student and Staff are both subtypes of Person. Alternatively, one can say that Person is asupertype of Student and Staff. Similarly, TA is a subtype of the Student and Person types, and so on. Thesubtype relationship is normally a preorder (reflexive and transitive) on types.A subtype relationship can also be viewed in terms of subsets. If σ is a subtype of τ , then all elementsof type σ are automatically elements of type τ .The ≤ symbol is typically used to denote the subtype relationship. Thus, Staff ≤ Person, RA ≤ Student,etc. Sometimes the symbol <: is used, but we will stick with ≤.2 Basic Subtyping RulesFormally, we write σ ≤ τ to indicate that σ is a subtype of τ . In denotational semantics, this is equivalentto saying [[σ ]] ⊆ [[τ ]]. The informal interpretation of this subtype relation is that anything of type σ can beused in a context that expects something of type τ . This is known as the subsumption rule:Γ ` e : σ σ ≤ τΓ ` e : τ.Two further general rules are:τ ≤ τσ ≤ τ τ ≤ ρσ ≤ ρwhich say that ≤ is reflexive and transitive, respectively, thus a preorder. In many cases, antisymmetryholds as well, making the subtyping relation a partial order, but this is not always true.The subtyping rules governing the types 1 and 0 are interesting:1• 1 (unit): Every type is a subtype of 1, that is, τ ≤ 1 for all types τ , thus 1 is the top type. If a contextexpects something of type 1, then it can accept any type. In Java, this is equivalent to the type Object.• 0 (void): Every type is a supertype of 0, i.e., 0 ≤ τ for all types τ , thus 0 is the bottom type. The type0 can be accepted by any context in lieu of any other type. In Java, this is equivalent to the Null type.3 Subtyping Rules for Product and Sum TypesThe subtyping rules for product and sum types are quite intuitive:σ ≤ σ0τ ≤ τ0σ ∗ τ ≤ σ0∗ τ0σ ≤ σ0τ ≤ τ0σ + τ ≤ σ0+ τ0These rules say that the product and sum type constructors are monotone with respect to the subtyperelation.4 Subtyping Rules for RecordsRecall our extensions to the grammar of e and τ for adding support for records types:e ::= · · · | {x1= e1, . . . , xn= en} | e.xτ ::= · · · | {x1: τ1, . . . , xn: τn}.We also had the following rule added to the small-step semantics:{x1= v1, . . . , xn= vn}.xi→ viand the following typing rules:Γ ` ei: τi, 1 ≤ i ≤ nΓ ` {x1= e1, . . . , xn= en} : {x1: τ1, . . . , xn: τn}Γ ` e : {x1: τ1, . . . , xn: τn}Γ ` e.xi: τiThere are two subtyping rules for records:• Depth subtyping: this defines the subtyping relation between two records that have the same numberof fields.σ1≤ τ1, σ2≤ τ2, . . . , σn≤ τn{x1: σ1, . . . , xn: σn} ≤ {x1: τ1, . . . , xn: τn}• Width subtyping: this defines the subtyping relation between two records that have different numberof fields.m ≤ n{x1: τ1, . . . , xn: τn} ≤ {x1: τ1, . . . , xm: τm}where the ≤ in the premise is integer comparison. Observe that in this case, the subtype has morecomponents than the supertype. This is analogous to the relationship between a subclass and asuperclass in which the subclass has all the components of the superclass, which it inherits from thesuperclass, but perhaps has some components that the superclass does not have.The depth and width subtyping rules for records can be combined into a single rule:m ≤ n σi≤ τi, 1 ≤ i ≤ n{x1: σ1, . . . , xn: σn} ≤ {x1: τ1, . . . , xm: τm}25 Subtyping Rules for VariantsRecords can be viewed as tagged product types of arbitrary length. The analogous extension for sum typesare called variant records or just variants.The depth subtyping rule for variants is the same as for records (replacing the records with variants).However, the width subtyping rule is different. Suppose we used a width s ubtyping rule of the same form asfor records. Intuitively, if σ ≤ τ , then this implies that anything of type σ can be used in a context expectingsomething of type τ . Suppose we now had a case statement that did pattern matching on something of typeτ. Our subtyping relation says that we can pass in something of type σ to this case statement and it willstill work. However, since τ has fewer components than σ and the case statement was originally written foran object of type τ, there will be values of σ for which no corresponding case exists. Thus, for variants, thedirection of the ≤ symbol in the premise needs to be reversed. In other words, for variants, the subtype willhave fewer components than the supertype.6 Function SubtypingBased on the subtyping rules we have encountered so far, our first impulse might be to write down somethingof the following form to describe the subtyping relation for functions:σ ≤ σ0τ ≤ τ0σ → τ ≤ σ0→ τ0However, this is incorrect. To see why, consider the following code fragment:let f : σ → τ = g inlet f0: σ0→ τ0= g0inlet t : σ0= v inf0(t)Supp ose σ ≤ σ0and τ ≤ τ0. By the rule above, we would have σ → τ ≤ σ0→ τ0, thus we should be able tosubstitute f for f0and the resulting program should be type correct, provided the original one was. But itis not: if σ0is a strict supertype of σ and the value v is of type σ0but not of type σ, then f will crash, sinceit exp e cts an input of type σ and it is not getting one.Actually, the incorrect typing rule given above was