%%% This is the scribe notes template for CS611 %%% There are several comments preceded by CS611: and boxed in %%%%'s %%% which indicate where macros should be altered to set up the header %%% for the paper. Your Notes should go at the comment SCRIBE NOTES GO HERE!. %%% In the various .sty files that accompany this .tex file you will %%% find LaTeX macros that make it easier to typeset inference rules %%% and programming language constructs. You must make sure that the %%% file proof.sty is in a path searched by LaTeX when you try to %%% use this file. Take a look to see what macros are available--it %%% will save you time and make the notes look better. Feel free to %%% extend the set of macros--post them to the newsgroup and contact %%% the course staff if you come up with some good ones so they can be %%% added to the template. %%% This template includes examples of how to use some of the macros %%% to give you an idea of how they work. (Delete the examples when %%% you do your scribing.) \documentclass{article} \usepackage{611-lecture} \usepackage{amsmath,amssymb,amsthm,amsfonts,comment,url} %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%% CS611: Please fill in these macros as appropriate: \lecture{31} %% Lecture number \title{Subtype Polymorphism} %% Title of lecture %\author{Mia Minnes, Nam Nguyen} %% name of scribe \date{20 November 2006} %% Date of lecture, e.g., 1 January 2001 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % See 611.sty for a variety of macros that will be helpful in % typesetting the lecture. Here are a few of particular interest: % % "x" x in keyword font (e.g., "if", "#t") % _x_ x in italics % \nm{n} n in slanted font (used for abbreviations) % e in angle brackets % \lt less-than sign % \gt greater-than sign % \SB{x} x in semantic brackets % \Tr x{y} x[[y]] with x in calligraphic font % (if x is more than a single character, use \Tr{x}{y}) \renewcommand\emptyset\varnothing \newcommand{\inL}{\ensuremath{\mathsf{inL}}} \newcommand{\inR}{\ensuremath{\mathsf{inR}}} \newcommand\caseof[3]{\mathsf{case}~{#1}~\mathsf{of}~{#2}~|~{#3}} \newtheorem{theorem}{Theorem} \newtheorem{lemma}[theorem]{Lemma} \newtheorem{proposition}[theorem]{Proposition} \newtheorem{corollary}[theorem]{Corollary} \newtheorem{definition}[theorem]{Definition} \newcommand{\Z}{\mathbb{Z}} \newcommand{\group}[1]{\left\langle{#1}\right\rangle} %\theoremstyle{definition} %\newtheorem*{defn}{Definition} \newcommand{\nondet}{\left[\!\kern1pt\right]} \renewcommand\phi\varphi \renewcommand\wp[2]{\mathsf{wp}~{#1}~{#2}} \newcommand\wlp[2]{\mathsf{wlp}~{#1}~{#2}} \renewcommand\({\begin{eqnarray*}} \renewcommand\){\end{eqnarray*}} \newcommand\LOOKUP[2]{\mathrm{LOOKUP}~{#1}~{#2}} \newcommand\UPDATE[3]{\mathrm{UPDATE}~{#1}~{#2}~{#3}} \newcommand\MALLOC[2]{\mathrm{MALLOC}~{#1}~{#2}} \newcommand\EMPTY{\mathrm{EMPTY\mbox{-}STORE}} \renewcommand\dom[1]{\mathrm{dom}\,{#1}} \newcommand\p[2]{\langle{#1},\,{#2}\rangle} \newcommand\bigcdot{\mathrel{\raisebox{1pt}{$\scriptscriptstyle\bullet$}}} \newcommand\holed[1]{[\,#1\,]} \newcommand\hole{\holed\bigcdot} \newcommand\context[1]{E\kern1pt\holed{#1}} \newcommand\contextHole{\context\bigcdot} \newcommand\goesto[2]{\underset{#2}{\overset{#1}\to}} \newcommand\ifthenelse[3]{\mathsf{if\ }#1\mathsf{\ then\ }#2\mathsf{\ else\ }#3} \newcommand\ifpthenelse[3]{\mathsf{ifp\ }#1\mathsf{\ then\ }#2\mathsf{\ else\ }#3} \newcommand\whiledo[2]{\mathsf{while\ }#1\mathsf{\ do\ }#2} \newcommand\letin[3]{\mathsf{let\ }#1 = #2\mathsf{\ in\ }#3} \newcommand\letrec[5]{\mathsf{letrec\ }#1 = #2\mathsf{\ and\ \ldots\ and\ }#3 = #4\mathsf{\ in\ }#5} \newcommand\letrecone[3]{\mathsf{letrec\ }#1 = #2\mathsf{\ in\ }#3} \newcommand\true{\ensuremath{\mathsf{true}}} \newcommand\false{\ensuremath{\mathsf{false}}} \newcommand\error{\ensuremath{\mathsf{error}}} \newcommand\pca[3]{\{#1\}\kern1pt{#2}\kern1pt\{#3\}} \newcommand\states{\Set{St}} \newcommand\rtc{^{\textstyle *}} \newcommand\sat\vDash \newcommand\force\vdash \newcommand\hyphen{\mbox{-}} \newcommand\lookup[2]{\nm{LOOKUP}~#1~\mquote{#2}} \newcommand\update[3]{\nm{UPDATE}~#1~\mquote{#2}~#3} \newcommand\SBk[1]{\SB{#1}k} \newcommand\fix[1]{\mathsf{fix}\,{#1}} \newlength\reasonwidth \setlength\reasonwidth{3cm} \newcommand\reasoning[1]{\def\longest{#1}\settowidth{\reasonwidth}{$\displaystyle\longest$}\addtolength{\reasonwidth}{5mm}} \newcommand\reason[2]{\makebox[\reasonwidth][l]{$\displaystyle{#1}$}\mbox{#2}} \renewcommand\inj[1]{\mathsf{in}_{#1}} \newcommand\proj[1]{\pi_{#1}} \newcommand{\dlt}{\sqsubseteq} \newcommand\floor[1]{\lfloor{#1}\rfloor} \newcommand\cf[1]{[\kern1pt{#1}\kern1pt]} \newcommand\SBpr[1]{\SB{#1}\,\phi\,\rho} \renewcommand\C[3]{\Tr C{#1}\kern1pt{#2}\kern1pt{#3}} \renewcommand\Cr[1]{\C{#1}\Gamma\rho} \newcommand\judge[3]{{#1}\force{#2}:{#3}} \newcommand\Gjudge[2]{\judge\Gamma{#1}{#2}}% \newcommand\forceUSN{\mathrel{\makebox[2pt][l]{$\force$}\raisebox{-3pt}[0pt][0pt]{\tiny{\textit{USN}}}}} \newcommand\judgeUSN[3]{{#1}\forceUSN{#2}:{#3}} \renewcommand\C[3]{\Tr C{#1}\kern1pt{#2}\kern1pt{#3}} \renewcommand\Cr[1]{\C{#1}\Gamma\rho} \newcommand\Irred[1]{\ensuremath{\mathrm{Irred}(#1)}} \newcommand\seq[3]{#1_{#2},\ldots,#1_{#3}} \newcommand\substtwo[5]{\subst{#1}{#2}{#3,\,#4/#5}} \newcommand\substlist[5]{\subst{#1}{#2}{#3,\ldots,#4/#5}} \newcommand\Unify[1]{\mathrm{Unify}(#1)} \newcommand\fa[2]{\forall{#1}\kern1pt.\kern1pt{#2}}% \newcommand\Judge[4]{\judge{#1;\,#2}{#3}{#4}} \renewcommand\infer[2]{\ensuremath{\dfrac{#2}{#1}}}% \newenvironment{proofof}[1]{\addtolength{\topsep}{1mm}\begin{trivlist}\item[]\hspace{\parindent}{\em Proof of #1.}}{\qed\end{trivlist}} \begin{document} \maketitle \section{Introduction} In this lecture, we attempt to extend the typed $\lambda$-calculus to support objects. In particular, we explore the concept 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 inventors Ole-Johan Dahl and Kristen Nygaard later went on to win the Turing award for their contribution to the field of object-oriented programming. Simula introduced a number of innovative features that have become the 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 of studying them. It is best illustrated by means of an example. \begin{center} \begin{picture}(0,140)(0,-20) \put(0,0){\makebox(0,0){RA}} \put(-80,0){\makebox(0,0){TA}} \put(-40,40){\makebox(0,0){Graduate}} \put(40,40){\makebox(0,0){Undergrad}} \put(0,80){\makebox(0,0){Student}} \put(80,80){\makebox(0,0){Staff}} \put(40,120){\makebox(0,0){Person}} \multiput(-3,6)(40,40)3{\line(-5,4){35}} \multiput(-77,6)(40,40)3{\line(5,4){35}} \put(0,-20){\makebox(0,0){Figure 1: A Subtype Hierarchy}} \end{picture} \end{center} This is an example of a hierarchy that describes a subtype relationship between different types. In this case, the types Student and Staff are both subtypes of Person. Alternatively, one can say that Person is a _supertype_ of Student and Staff. Similarly, TA is a subtype of the Student and Person types, and so on. The subtype relationship is normally a preorder (reflexive and transitive) on types. A subtype relationship can also be viewed in terms of subsets. If $\sigma$ is a subtype of $\tau$, then all elements of type $\sigma$ are automatically elements of type $\tau$. The $\leq$ symbol is typically used to denote the subtype relationship. Thus, Staff $\leq$ Person, RA $\leq$ Student, etc. Sometimes the symbol $\lt:$ is used, but we will stick with $\leq$. \section{Basic Subtyping Rules} Formally, we write $\sigma \leq \tau$ to indicate that $\sigma$ is a subtype of $\tau$. In denotational semantics, this is equivalent to saying $\SB{\sigma}\subseteq\SB{\tau}$. The informal interpretation of this subtype relation is that anything of type $\sigma$ can be used in a context that expects something of type $\tau$. This is known as the _subsumption_ rule: \[ \frac {\Gamma\vdash e:\sigma\qquad\sigma\leq\tau} {\Gamma\vdash e:\tau}. \] Two further general rules are: \( \tau \leq \tau &\qquad& \frac{\sigma \leq \tau\quad\tau \leq \rho}{\sigma \leq \rho} \) which say that $\leq$ is reflexive and transitive, respectively, thus a preorder. In many cases, antisymmetry holds 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: \begin{itemize} \item 1 ("unit"): Every type is a subtype of 1, that is, $\tau\leq 1$ for all types $\tau$, thus 1 is the top type. If a context expects something of type 1, then it can accept any type. In Java, this is equivalent to the type Object. \item 0 ("void"): Every type is a supertype of 0, i.e., $0 \leq \tau$ for all types $\tau$, thus 0 is the bottom type. The type 0 can be accepted by any context in lieu of any other type. In Java, this is equivalent to the Null type. \end{itemize} \section{Subtyping Rules for Product and Sum Types} The subtyping rules for product and sum types are quite intuitive: \begin{center} \begin{tabular}{cc} \infer{\sigma * \tau \leq \sigma' * \tau'}{\sigma \leq \sigma'\quad\tau \leq \tau'} & \infer{\sigma + \tau \leq \sigma' + \tau'}{\sigma \leq \sigma'\quad\tau \leq \tau'} \end{tabular} \end{center} These rules say that the product and sum type constructors are monotone with respect to the subtype relation. \section{Subtyping Rules for Records} Recall our extensions to the grammar of $e$ and $\tau$ for adding support for records types: \( e &::=& \cdots \bnf \{x_1 = e_1, \ldots, x_n = e_n\} \bnf e.x\\ \tau &::=& \cdots \bnf \{x_1:\tau_1, \ldots, x_n:\tau_n\}. \) We also had the following rule added to the small-step semantics: \( \{x_1=v_1, \ldots, x_n=v_n\}.x_i &\to& v_i \) and the following typing rules: \( \infer{\judge\Gamma{\{x_1=e_1, \ldots, x_n=e_n\}}{\{x_1:\tau_1, \ldots, x_n:\tau_n\}}}{\judge\Gamma{e_i}{\tau_i},\ 1\leq i\leq n} &\qquad& \infer{\judge\Gamma{e.x_i}{\tau_i}}{\judge\Gamma e{\{x_1:\tau_1, \ldots, x_n:\tau_n\}}} \) There are two subtyping rules for records: \begin{itemize} \item _Depth subtyping_: this defines the subtyping relation between two records that have the same number of fields. \[ \infer {\{x_1:\sigma_1, \ldots, x_n:\sigma_n\} \leq \{x_1:\tau_1, \ldots, x_n:\tau_n\}} {\sigma_1 \leq \tau_1,\ \sigma_2 \leq \tau_2,\ \ldots,\ \sigma_n \leq \tau_n} \] \item _Width subtyping_: this defines the subtyping relation between two records that have different number of fields. \[ \infer{\{x_1:\tau_1, \ldots, x_n:\tau_n\} \leq \{x_1:\tau_1, \ldots, x_m:\tau_m\}}{m \leq n} \] where the $\leq$ in the premise is integer comparison. Observe that in this case, the subtype has more components than the supertype. This is analogous to the relationship between a subclass and a superclass in which the subclass has all the components of the superclass, which it inherits from the superclass, but perhaps has some components that the superclass does not have. \end{itemize} The depth and width subtyping rules for records can be combined into a single rule: \[ \infer {\{x_1:\sigma_1, \ldots, x_n:\sigma_n\} \leq \{x_1:\tau_1, \ldots, x_m:\tau_m\}}{m \leq n\qquad\sigma_i \leq \tau_i,\ 1\leq i\leq n} \] \section{Subtyping Rules for Variants} Records can be viewed as tagged product types of arbitrary length. The analogous extension for sum types are 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 subtyping rule of the same form as for records. Intuitively, if $\sigma \leq \tau$, then this implies that anything of type $\sigma$ can be used in a context expecting something of type $\tau$. Suppose we now had a "case" statement that did pattern matching on something of type $\tau$. Our subtyping relation says that we can pass in something of type $\sigma$ to this "case" statement and it will still work. However, since $\tau$ has fewer components than $\sigma$ and the "case" statement was originally written for an object of type $\tau$, there will be values of $\sigma$ for which no corresponding case exists. Thus, for variants, the direction of the $\leq$ symbol in the premise needs to be reversed. In other words, for variants, the subtype will have _fewer_ components than the supertype. \section{Function Subtyping} Based on the subtyping rules we have encountered so far, our first impulse might be to write down something of the following form to describe the subtyping relation for functions: \[ \infer{\sigma\to\tau\leq\sigma'\to\tau'}{\sigma\leq\sigma'\quad\tau\leq\tau'} \] However, this is incorrect. To see why, consider the following code fragment: \begin{quote} $\letin{f:\sigma\to\tau}g{}$\\ $\phantom{dd}\letin{f':\sigma'\to\tau'}{g'}{}$\\ $\phantom{dddd}\letin{t:\sigma'}v{}$\\ $\phantom{dddddd}f'(t)$ \end{quote} Suppose $\sigma\leq\sigma'$ and $\tau\leq\tau'$. By the rule above, we would have $\sigma\to\tau\leq\sigma'\to\tau'$, thus we should be able to substitute $f$ for $f'$ and the resulting program should be type correct, provided the original one was. But it is not: if $\sigma'$ is a strict supertype of $\sigma$ and the value $v$ is of type $\sigma'$ but not of type $\sigma$, then $f$ will crash, since it expects an input of type $\sigma$ and it is not getting one. Actually, the incorrect typing rule given above was implemented in the language Eiffel, and runtime type checking had to be added later to make the language type safe. The correct subtyping rule for functions is: \[ \infer{\sigma\to\tau\leq\sigma'\to\tau'}{\sigma'\leq \sigma\quad\tau\leq\tau'} \] Note that the ordering on the domain is reversed in the premise. Succinctly stated, a function $f$ of type $\sigma\to\tau$ can safely take any input of any subtype $\sigma'$ of $\sigma$, and produces a value that can be taken to be of any supertype $\tau'$ of $\tau$; thus we are free to regard $f$ as a function of type $\sigma'\to\tau'$. In all the type constructors we had seen so far, the subtyping relation was preserved. With the function space constructor, however, the subtyping relation on the domain is reversed. We say that the function type constructor $\to$ is _contravariant_ in the domain and _covariant_ in the range. \section{Subtyping Rules for References} Recall the extensions to the grammar of $e$ and $\tau$ for adding support for references: \( e &::=& \cdots \bnf "ref"~e \bnf !e \bnf e_1 := e_2\\ \tau &::=& \cdots \bnf \tau~"ref" \) The typing rules are \medskip \begin{center} \begin{tabular}{c@{\qquad}c@{\qquad}c} \infer{\judge\Gamma{"ref"~e}{\tau~"ref"}}{\judge\Gamma e\tau} & \infer{\judge\Gamma{!e}\tau}{\judge\Gamma e{\tau~"ref"}} & \infer{\judge\Gamma{e_1:=e_2}1}{\judge\Gamma{e_1}{\tau~"ref"}\quad\judge\Gamma{e_2}\tau} \end{tabular} \end{center} \medskip As for subtyping, once again our first impulse might be to write down something like the following: \[ \infer{\sigma~"ref" \leq \tau~"ref"} {\sigma \leq \tau} \] However, again this would be incorrect. The problem is that to be safe, a "ref" appearing on the left-hand side of an assignment operator should be contravariant. Consider the following example: \begin{quote} $\letin{x:\mathit{Square}~"ref"}{"ref"~\mathit{square}}{}$\\ $\phantom{dd}\letin{y:\mathit{Shape}~"ref"}x{}$\\ $\phantom{dddd}(y:=\mathit{circle};~(!x).\mathit{side})$ \end{quote} Even though this code type-checks with the given subtyping rule for reference types, it is not type-correct, since in the last line $x$ does not refer to a square anymore. This problem actually exists in Java when using arrays, as the designers incorrectly used the rule given above. Consequently, a runtime check is necessary. \begin{flushleft} \verb+public class Test {+\\ \mbox{}\phantom{dd}\verb+public static void main(String[] args) {+\\ \mbox{}\phantom{dddd}\verb+B[] b = new B[1];+\\ \mbox{}\phantom{dddd}\verb+A[] a = b;+\\ \mbox{}\phantom{dddd}\verb+a[0] = new A();+\\ \mbox{}\phantom{dd}\verb+}+\\ \verb+}+\\ \mbox{}\\ \verb+class A {}+\\ \verb+class B extends A {}+\\ \mbox{}\\ \verb+Exception in thread ``main'' java.lang.ArrayStoreException: A+\\ \mbox{}\phantom{dd}\verb+at Test.main(Test.java:5)+ \end{flushleft} In order to overcome this problem we must use the correct rule below: \[ \infer{\sigma~"ref" \leq \tau~"ref"} {\sigma \leq \tau~~\tau \leq \sigma} \] The subtyping rule for references is thus both covariant and contravariant. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \end{document}