Classes = Objects + Data Abstraction

Classes = Ob jects + Data Abstraction

Kathleen Fisher and John C. Mitchell

Computer Science Department, Stanford University, Stanford, CA 94305

fkfisher,[email protected]

January 11, 1996

Abstract

We describ e a typ e-theoretic foundation for ob ject systems that include \interface typ es" and

\implementation typ es," in the pro cess accounting for access controls suchasC private,

protected and public levels of visibility. Our approach b egins with a basic ob ject calculus

that provides a notion of ob ject, metho d lo okup, and ob ject extension an ob ject-based form

of inheritance. In this calculus, the typ e of an ob ject gives an interface, as a set of metho ds

public memb er functions and their typ es, but do es not imply any implementation prop erties

such as the presence or layout of any hidden internal data. We extend the core ob ject calculus

with a higher-order form of data abstraction mechanism that allows us to declare sup ertyp es

of an abstract typ e and a list of metho ds guaranteed not to b e present. This results in a

exible framework for studying and improving practical programming languages where the typ e

of an ob ject gives certain implementation guarantees, suchaswould b e needed to statically

determine the o set of a function in a metho d lo okup table or safely implement binary op erations

without exp osing the internal representation of ob jects. We provetyp e soundness for the entire

language using op erational semantics and an analysis of typing derivations. Two insights that

are immediate consequences of our analysis are the identi cation of an anomaly asso ciated with

C private virtual functions and a principled, typ e-theoretic explanation for the rst time,

as far as we know of the link b etween subtyping and inheritance in C , Ei el and related

languages.

1 Intro duction

In theoretical studies of ob ject systems, suchas[AC94b, Bru93, FHM94, PT94] and the earlier

pap ers app earing in [GM94], typ es are viewed as interfaces to ob jects. This means that the typ e

of an ob ject lists the op erations on the ob ject, generally as metho d names and return typ es, but

do es not restrict its implementation. As a result, ob jects of the same typ e mayhave arbitrarily

di erentinternal representations. In contrast, the typ e of an ob ject in common practical ob ject-

oriented languages such as Ei el [Mey92] and C [Str86, ES90] may imp ose some implementation

constraints. In particular, although the \private" internal data of an ob ject is not accessible

outside the memb er functions of the class, all ob jects of the same class must have all of the private

internal data listed in the class declaration. In this pap er, we presentatyp e-theoretic framework

that incorp orates b oth forms of typ e. We explain the basic principles by extending a core ob ject

calculus with a standard higher-order data abstraction mechanism as in [MP88, CW85]. We also

Supp orted in part byaFannie and John Hertz Foundation Fellowship and NSF Grant CCR-9303099.

Supp orted in part by NSF Grant CCR-9303099 and the TRWFoundation. 1

discuss a sp ecial-purp ose syntax that is closer to common practice and that eliminates a few minor

syntactic inconveniences in our sp eci c use of standard abstract data typ e declarations.

From a programming p oint of view, \interface" typ es are often more exible than typ es that

constrain the implementation of ob jects. With this form of typ e, we could de ne a single typ e

of matrix ob jects, for example, then represent dense matrices with one form of ob ject and sparse

matrices with another. If the typ e only gives the interface of an ob ject, then b oth matrix represen-

tations could have the same typ e and therefore b e used interchangeably in any program. This kind

of exibili ty is particularly useful when we write library op erations on matrices without assuming

any particular implementation. Such library functions may b e written using a standard interface

typ e, without concern for how matrices might b e implemented in later or earlier developmentof

a software system.

Typ es that restrict the implementations of ob jects are also imp ortant. If we know that all

p oint ob jects inherit a sp eci c representation of x and y co ordinates, for example, then a program

may b e optimized to take advantage of this static guarantee. The usual implementations of C ,

for example, use typ e information to statically calculate the o set of memb er data relativetothe

starting address of the ob ject. A similar calculation is used to nd the o set of virtual member

functions in the v-table at compile time; see [ES90, Section 10.7c]. Such optimizations are not

p ossible in an untyp ed language such as Smalltalk [GR83] and would not b e p ossible in a typ ed

language where ob jects of a single typ e could have arbitrarily dissimilar implementations.

A second, more metho dological reason that programmers maybeinterested in implementation

typ es is that there are greater guarantees of b ehavioral similarity across subtyp e hierarchies. More

sp eci cally, traditional typ e systems generally give useful information ab out the signature or do-

main and range of op erations. This is a very weak form of sp eci cation and, in many programming

situations, it is desirable to have more detailed guarantees. While b ehavioral sp eci cations are dif-

cult to manipulate e ectively,wehave a crude but useful approximation when typ es x part of

the implementation of an ob ject. To return to p oints, for example, if we know that all subtyp es of

p oint share a common implementation of a basic function like move , then the typ e system, in e ect,

guarantees a b ehavioral prop ertyofpoints. This maybeachieved in our framework if move is

private or if we add the straightforward capability of restricting rede nition of protected or public

metho ds.

A more subtle reason to use typ es that restrict the implementations of ob jects has to do with

the implementation of binary op erations. In an ob ject-oriented context, a binary op eration on typ e

A is realized as a memb er function that requires another A ob ject as a parameter. In a language

where all ob jects of typ e A share some common representation, it is p ossible for an A member

function to safely access part of the private internal representation of another A ob ject. A simple

example of this arises with set ob jects that have only a memb ership test and a union op eration

in their public interfaces. With interface typ es, some ob jects of typ e set might b e represented

internally using bit-vectors, while others might use linked lists. In this case, there is no typ e-safe

way to implement union, since no single op eration will access b oth a bit-vector and a linked list

correctly. With only interface typ es, it is necessary to extend the public interface of b oth kinds of

sets to make this op eration p ossible. In contrast, if the typ e of an ob ject conveys implementation

information, then a less exible but typ e-safe implementation of set union is p ossible. In this case,

all set ob jects would have one representation and a union op eration could b e implemented by taking

advantage of this uniformity.

This pap er presents a provably sound typ e system, based on accepted typ e-theoretic principles,

that allows us to write b oth \interface typ es" and \implementation typ es". The system is relatively

simple in outline, since it may b e viewed as a straightforward combination of basic constructs that 2

have b een studied previously.However, there are a numb er of details involving subtyp e assertions

ab out abstract typ es, extensions to abstract typ es, covariance and contravariance of metho ds, and

the absence of metho ds that make the exact details of the system relatively subtle. In summary, the

pap er has three main p oints: i the general view that classes corresp ond to abstract data typ es, ii

a precise formulation of a higher-order abstract typ e mechanism and a exible underlying ob ject

calculus that together make it p ossible to establish a corresp ondence b etween C -style classes and

abstract data typ es whose representations are ob jects, iii a pro of of typ e soundness for the typ e

system that arises from this analysis. While there is a folkloric b elief that C and Ei el classes

provide a form of data abstraction, we b elieve that this is the rst technical account suggesting a

precise corresp ondence b etween class constructs and a standard non-ob ject-oriented form of data

abstraction.

Our presentation of classes as abstract data typ es requires a numb er of op erations on ob jects.

Sp eci cally, the underlying ob ject calculus without data abstraction must provide a basic form of

ob ject that allow ustoinvoke metho ds of an ob ject, extend ob jects with new metho ds, and replace

existing metho ds. Moreover, in order to capture the form of subtyping presentintyp ed ob ject-

oriented languages, wemust have at least the usual form of subtyping b etween ob ject typ es. This

muchwas already provided by our previous ob ject calculus, presented in [FHM94, FM95]; similar

primitives are also provided in alternative approaches suchas[AC94b,AC94a].

In adding a data abstraction mechanism, wemust incorp orate subtyp e sp eci cations, negative

information absence of metho ds, and variance information in abstract typ e declarations. This is

so that abstract typ es are extensible in essentially the same way as their underlying representations.

Therefore, we extend our basic calculus from [FHM94, FM95] with more detailed static information

ab out typ e variables and since most op erations are done on functions from typ es to so-called

rows rowvariables. While the intuitive decomp osition of classes into data abstraction and ob ject

primitives is essentially straightforward, the need to maintain detailed information ab out subtyping

prop erties and extensibility of abstract typ es leads to certain technical complications and subtleties

that had to b e overcome in developing this analysis.

A detail for readers of [FHM94] is that the \class" typ es of that pap er were interface typ es,

not classes in the sense of a form of ob ject typ e that includes implementation information. We

therefore renamed them \pro" for prototyp e typ es in [FM95] and continue that terminology here.

2 Overview by Example

2.1 Protection levels

Each class in an ob ject-oriented program has two kinds of external clients: sections of the program

that use ob jects created from the class and classes that derive new classes from the original. Since

the metho ds of a class may refer to each other, the class also has an internal \client," namely

itself. We therefore asso ciate three interfaces with each class. Using C terminology, these may

b e distinguished as follows:

Private metho ds are only accessible within the implementation of the class,

Protected metho ds are only accessible in the implementation of the class and derived classes,

Public metho ds may b e accessible, through ob jects of the class, in any mo dule of the program.

One goal of this pap er is to showhowwe can asso ciate a di erenttyp e with eachinterface and

use essentially standard typ e-theoretic constructs to restrict visibility in each part of a program 3

appropriately. In doing so, wepay particular attention to the fact that although the private or

protected metho ds may not b e accessible in certain contexts, it is imp ortant for the typ e system

to guarantee their existence.

2.2 Point and color p oint classes

Using C -like syntax, we might declare classes of p oints and colored p oints as shown b elow. For

simplicity,we use only one-dimensional p oints.

class Point

private x : int;

protected setX : int -> Point;

public getX : int;

mv : int -> Point;

newPoint : int -> Point;

end;

class ColorPoint : Point

private c : color;

protected setC : color -> ColorPoint;

public getC : color;

newColorPoint : color -> int -> ColorPoint

end;

metho ds are used to assign to private x-co ordinate or color data, and get Intuitively, the set

metho ds are used to read the values of the data. The move metho d mv changes the x-co ordinate of a

p oint or colored p oint. These classes re ect a common idiom of C programming, where the basic

data elds are kept private so that the class implementor maychange the internal representation

without invalidating client co de. Protected metho ds make it p ossible for derived classes to change

the values of private data, without providing the same capability outside of derived classes.

In C and in the pseudo-co de ab ove, each class contains a sp ecial function called a constructor

for the class. Here the constructor is distinguished by the syntactic form newClassname . Since all

ob jects of a class are created by calling a class constructor, it is imp ortant to b e able to call the

constructor function b efore any ob jects have b een created. Therefore, unlike the other functions

listed in the class declarations, the class constructor is not a metho d; it do es not b elong to ob jects

of the class. Constructors are included in class declarations primarily as a syntactic convenience.

2.3 Interface typ e expressions

In translating the pseudo-co de ab oveinto a more precise form, we write a typ e expression for

eachinterface of each class, resulting in six distinct but related typ es. In hop es that this practice

will provide useful mnemonics, we follow a systematic naming convention where, for class A ,we

call the typ e expressions for the public, protected, and private interfaces A ; A , and A ,

pub prot priv

resp ectively.

Although eachinterface is essentially a list of metho ds names and their typ es, it is necessary

to use a typ e function instead of a typ e for eachinterface. The reason is that the typ e asso ciated

with the ob jects instantiated from a given class is recursively de ned; this typ e is a xed-p ointof

atyp e function. Point-wise subtyping b etween suchtyp e functions is the critical relation b etween

interfaces for typ e-checking inheritance. 4

For Point , this metho dology gives us the following typ e functions, using the form hh ::: ii for

ob ject interface typ es:

def

Point = t hhgetX : int; mv : int tii

pub

def

! !

Point = t hhsetX : int t; getX : int; mv : int tii

prot

def

! !

Point = t hhx : int; setX : int t; getX : int; mv : int tii

priv

These interface functions are formed from the class declaration for Point by replacing o ccurrences

of Point byatyp e variable t and lamb da-abstracting to obtain a typ e function. We will use row

variables to range over suchtyp e functions, which map typ es to nite lists of metho d/typ e pairs.

The analogous interfaces for ColorPoint are written using a free rowvariable p , which will b e

b ound to the abstract typ e-function for p oints in the scop e where the ColorPoint interfaces will

app ear:

def

ColorPoint = t hhpt j getC : Colorii

pub

def

ColorPoint = t hhpt j setC : Color t; getC : Colorii

prot

def

ColorPoint = t hhpt j c : Color; setC : Color t; getC : Colorii

priv

Since the sup ertyping b ounds on identi er p will give all of the relevant protected or public

Point metho ds, there is no need to list the metho ds inherited from Point . Consequently these

ColorPoint interfaces list exactly the same metho ds as our pseudo-co de ColorPoint class. Since

the variable p will b e \existentially b ound" in an abstract data typ e declaration, the o ccurrence

of p in each expression will guarantee that all the private metho ds of Point ob jects are presentin

every ColorPoint ob ject, without exp osing any other information ab out private Point metho ds.

So-called \kind" information in the declaration of p will guarantee that metho ds named c; setC;

and getC are not present, making it typ e-safe to extend p ob jects with these new metho ds.

2.4 Implementations

A class implementation sp eci es an ob ject layout and set of metho d b o dies co de for the metho ds of

the ob jects. In our approach, the ob ject layout will b e given bya typ e expression and the metho d

b o dies will b e part of the constructor function. Following general principles of data abstraction,

the metho d b o dies may rely on asp ects of the representation that are hidden from other parts of

the program.

We use a subtyp e-b ounded form of data abstraction based on existential typ es [MP88, CW85].

Using this formalism, the implementation of p oints will b e given by a pair with subtyp e-b ounded

existential typ e of the form

fjp <:::::: = P ; ConsImp jg

priv p

consisting of the private interface P for p oints and a constructor function ConsImp that might

priv p

use an initial value for the x -co ordinate, for example, to return a new p oint ob ject. Our framework

allows anynumb er of constructor functions, or other \non-virtual" op erations to b e provided here.

However, for simplicity,we discuss only the sp ecial case of one constructor p er class. For the

moment, we leave the sup ertyp e b ound, indicated by the ellipsis :::above, unsp eci ed since we

later discuss two separate approaches, a minimal one in whichwe give the protected interface here

later restricting the program view to the public interface and a more sp ecial-purp ose approachin

which b oth the protected and public interfaces are sp eci ed in the class implementation. The \kind" 5

Abstype p <: P :: T ! fc; getC; setCg; ;

prot

with newPoint : Int pro u pu

is fjp < : P :: T ! fc; getC; setCg; ; = P ; Imp jg

prot priv p

Abstype cp < : CP :: T ! ;; ;

prot

! !

cp u with newColorPoint : Int Color pro u

is fjcp <: CP :: T ! ;; ; = CP ; Imp jg

prot priv cp

Abstype p < : P :: T ! ;; ;

pub

pt with newPoint : Int ob j t

is fjp <: P :: T ! ;; ; = p; newPointjg

pub

Abstype cp <: CP :: T ! ;; ;

pub

! !

cp t with newColorPoint : Int Color ob j t

is fjcp <: P :: T ! ;; ; = cp; newColorPointjg

pub

hProgrami

Figure 1: Nested abstract data typ es for p oints and colored p oint classes.

will indicate that we are declaring an abstract typ e function, list metho ds that are guaranteed

not to b e present in the implementation of p oints, and describ e the variance of p oint ob jects. The

variance information is needed to infer subtyping relationships for ob ject typ es that contain row

variable p .

The implementation of ColorPoint similarly has the form

fjcp <:::::: = CP ; ConsImp jg

priv cp

where the constructor ConsImp , rst invokes the Point class constructor newPoint , then extends

the resulting prototyp e with the new metho ds c; setc; and getc . De nitions of the Point and

ColorPoint class constructors are given in Section 3.4.

2.5 Class hierarchies as nested abstract typ es

Our basic view of classes and implementation typ es is that the class-based pseudo-co de in Section 2.2

may b e regarded as sugar for the sequence of nested abstract data typ e Abstype declarations

given in Figure 1. Since it is syntactically awkward to use two declarations p er class, one giving the

protected interface and the other the public interface, we discuss alternate syntactic presentations

in Section 3.5.

In order, the four abstract typ e declarations give the protected view of Point, the protected

view of ColorPoint, the public view of Point, and the public view of ColorPoint. The nesting

structure allows the implementation of ColorPoint to refer to the protected view of Point and

allows the program to refer to public views of b oth classes. 6

The two inner declarations hide the protected view of a class by redeclaring the same typ e name

and constructor and exp osing the public view with a di erenttyp e, as discussed b elow. Since the

implementation of the public view, in each case, is exactly the same as the implementation of the

protected view, hiding the protected metho ds is the only function of the two inner declarations.

We admit that reusing b ound variables is a bit of a \hack," but this is a relatively minor issue that

can b e solved by departing from the simple blo ck-structured scoping mechanism we use here.

One distinction b etween the protected and public views is that the constructors for the protected

view return an ob ject with a pro typ e while the public view constructors return ob jects with ob j

typ es. These twotyp es from our underlying ob ject calculus allow di erent sets of op erations on

ob jects. Sp eci cally, new metho ds may b e added to an ob ject with a pro typ e and existing metho ds

can b e overridden. If an ob ject has an ob j typ e, on the other hand, the only op eration is to invoke

a metho d of the ob ject. Since wehave di erent sets of op erations, there are di erent subtyping

rules: the subtyping relation is relatively richbetween ob j typ es, while the only sup ertyp es of a

pro typ e are ob ject typ es. Intuitively, this means that the metho ds of an ob ject may b e mo di ed

or extended when it is used as a prototyp e, but not once it is \promoted" to a memberofan ob j

typ e. While the distinction b etween these two kinds of typ es is convenient for our purp oses here, it

was originally devised as a mechanism for obtaining nontrivial subtyping in the presence of ob ject

inheritance primitives ob ject extension and metho d rede nition.

3 Ob ject calculus and typ e system

3.1 The calculus

The expressions of our core calculus are untyp ed lamb da terms, includin g variable x , application

e e and lamb da abstraction x: e , extended with four ob ject forms:

1 2

hi the empty prototyp e or ob ject

e m send message m to prototyp e or ob ject e

he + m=e i extend prototyp e e with new metho d m having b o dy e

1 2 1 2

he m= e i replace prototyp e e 's metho d b o dy for m by e

1 2 1 2

These expressions are the same as in [FHM94, FM95]. However, the typ e system used in the

present pap er is more detailed. We extend this core calculus with two encapsulation primitives:

Abstype r <: R :: with x : is e in e

1 2

fjr <: R :: = R ; ejg

The rst is used to provide limited access to implementation e in client e . Typ e expression

1 2

r < : R :: and assumption x : provide the interface for this access. The typ e system will

require expression e to have the form fjr < : R :: = R; ejg, which is the implementation of

the abstraction. The comp onents of these expressions will b e explained in more detail after we

intro duce the typ e system.

3.2 Op erational semantics

The op erational semantics include -reduction for evaluating function applications and a rule

for evaluating message sends:

eval

he m=e im ! e he m=e i

1 2 2 1 2 7

where may b e either +or.We also need various b o okkeeping rules to access metho ds

de ned within e . These b o okkeeping rules app ear in App endix A; they are explained in full in

[FHM94]. The reduction rule Absty pe for abstract data typ e declarations is:

eval

0 0

Abstype r < : R :: with x : is fjr <: R :: = R ; e jg in e ! [R =r; e =x]e

1 2 1 2

w w

3.3 Static Typ e System

The typ e expressions, given in App endix B, include typ e variables, function typ es, pro typ es, ob j

typ es, and existential typ es. To reduce the complexity of the typ e system, these typ es are divided

into two categories. The unquanti ed, monotyp es are indicated using metavariables ; ; ;:::.

The quanti ed typ es, indicated using metavariables ; ; ;:::,may contain existential quanti ers.

A row is a nite list of method name, type pairs. Row expressions app ear as sub expressions

of typ e expressions, with rows and typ es distinguished by kinds. Intuitively, the elements of kind

fm~ g; V are the rows that do not include the metho d names in fm~ g and whose the free typ e

variables app ear with variance indicated in variance set V . Wekeep track of the absence of

metho ds in order to guarantee that metho ds are not multiply de ned. The variance information,

which tells whether a variable app ears monotonically,antimonotonically, or neither, is necessary

for subtyping judgements involving typ es of the form pro t R or ob j t R since R may contain

rowvariables. Typ e functions, which arise as row expressions with kind T ! fm~ g; V , are used

to infer a form of higher-order p olymorphism for metho d b o dies and to provide typ e interfaces to

encapsulated implementations. The annotation a indicates the variance of the abstracted variable.

Toavoid unnecessary rep etition in our presentation, we use the meta-variable prob j for either

hhm : ;:::;m : ii are ob jects e such that ob j or pro.Intuitively, the elements of typ e prob j t

1 1 k k

for 1 i k , the result of e m is a value of typ e .However, since the b ound typ e variable t

i i

may app ear free in , the typ e of e m is actually the result of replacing each free o ccurrence of

i i

t in by prob j t hhm : ;:::;m : ii. Because of this substitution, prob j t hh:::ii is e ectively

i 1 1 k k

a sp ecial form of recursively-de ned typ e.

The typing rule for sending a message to an ob ject is

e : prob j t R

;t:ft g R<: hhm:ii

pr obj

em :[prob j t R=t]

where the substitution for t in re ects the recursive nature of pro and ob j typ es. This rule di ers

from the ones given in [FHM94, FM95]by requiring only that wemay derive;t:ft g R<: hhm:ii

instead of the more stringent requirement that R hhRjm :ii. This relaxation p ermits us to typ e

message sends to ob jects whose typ es may b e partially abstract i.e.,typ es containing rowvari-

ables. Another thing to notice ab out this rule is the subscript w on the subtyping judgment. This

symb ol indicates that only width subtyping was used to reach this conclusion. Our system supp orts

b oth width and depth subtyping on ob ject typ es; however, for soundness of certain op erations, it

is essential to keep track of exactly where depth subtyping o ccurs.

The rule for metho d override is as follows:

R e : pro u

;u:fu g R<: hhm:ii

;I e :[pro u r u=t]t

r 2

pr o ov er

he m=e i : pro u R

1 2 8

where I = r<: t: R ::T ! ;; InvarV .

The primary di erence b etween this rule and the one given in [FHM94, FM95] is again the relaxation

of the requirement that R b e of the form hhR j m : ii , which p ermits us to override metho ds in

ob jects with partially abstract typ es.

The distinction b etween pro and ob j typ es is that the former allows rede nition or extension of

metho ds, while the latter gives subtyping instead. An inessential artifact of our calculus is that we

may use the same untyp ed terms for prototyp es and ob jects. We might like to use this coincidence

to advantage by using the following rule along with subsumption to convert prototyp es to ob jects:

R : T ob j u

seal-unsound

pro u R<:ob j u R

where the hyp othesis ob j u R : T ensures that ob j u R is well formed. Unfortunately, this

rule is problematic when the variable u app ears contravariantly in R . Hence we need a more

complicated rule that we combine with the rule for ob j subtyping since they b oth have the same

form:

;t : ft g R <: R

1 2

;t : ft g R ::M; V

Vart; V 2f?;+g

<: obj

prob j t R < : ob j t R

1 2

Because R and R in this rule might contain rowvariables, we cannot use their syntactic form

1 2

to determine whether the critical typ e variable app ears covariantly monotonically. Therefore, we

app eal to the kind of R , which contains so-called variance monotonicityorantimonotonicity

information. The auxiliary function Vart; V gives the variance of typ e variable of t in variance

set V . If Vart; V is ? , then t do es not app ear in R , and hence is vacuously covariant. If

Vart; V is + , then t app ears covariantly. In either case, the consequent of the rule follows from

the premises. Since the subscript B on the subtyp e relation is unconstrained, this rule gives us

subtyping in b oth width and depth for ob j typ es . This rule also has the somewhat unfortunate

prop erty that we cannot convert prototyp es to ob j typ e if there are metho ds that are contravariant

in the b ound typ e variable. However, this app ears to b e a fundamental trade-o and limitation.

The rule for forming a class implementation: is the standard rule for existential intro duction,

extended to address kinding and sup ertyping constraints.

R ::

R <: R

e :[R =r ]

9 <: intr o

fjr<: R :: = R ;ejg:9r<: R ::

w w

The rule for existential typ es is standard as well. The full typ e system app ears in App endix C.

3.4 Examples

The Point class constructor Imp from Section 2.4 may b e written as follows:

initX h x = self initX;

newX hself x = self newXi; setX = self

getX = self self x;

mv = self dx self setXdx + self getXi

The ColorPoint constructor Imp rst invokes the Point class constructor newPoint , which

is implemented by the ab ove Imp function then extends the resulting prototyp e with the new

metho ds c; setc; and getc :

iX iC hhhhnewPointiX + c = self iCi

+ getC = self self ci

+ setC = self newC hself c = self newCiii

By rst calling the constructor for the Point class, the ColorPoint class p ermits the parent

Point class to build the parts of the ColorPoint ob jects inherited from Point , including the

private comp onents that the ColorPoint class cannot access.

3.5 An explicit class construct

Although the pattern of nested abstract data typ e declarations discussed in Section 2.5 gives us

some useful insightinto classes, this is an \enco ding" of a relatively complex construct into a

pattern of use of two simpler ones; it not a class construct that could b e used as the basis for

programming language design. In this brief section, we discuss an alternate \foundational ob ject

calculus" with classes taken as basic instead of derived from abstract data typ e declarations. While

additional redesign is p ossible, we con ne ourselves to replacing patterns of abstyp e by a single

class construct; we do not consider mo di cations of the underlying core ob ject calculus. As a

simplifying syntactic assumption, we continue to work with blo ck-structured syntax, instead of a

more complicated mo dule formalism with visibili ty controlled by explicit uses declarations.

A simple construct that may b e used in place of standard abstype is a class declaration of the

form

Class p <: P_prot <: P_pub :: kind_p with newPpars_p is

and q <: Q_prot <: Q_pub :: kind_q with newQpars_q is

and ...

and r <: R_prot <: R_pub :: kind_r with newRpars_r is

Program

end

We can derive direct typing rules for this construct using the translation into nested abstype 's.

The idea is that classes q :::r may declare subtyp es of p . Therefore, this declaration binds

p and newP in the subsequent class declaration clauses and in Program .However, the subtyping

information ab out p and typ e of newP will b e di erent in the two scop es. Sp eci cally, the clauses

prot :: kind p and giving p ossible subtyp es of p are typ e-checked using the assumptions p < : P

newP : pars p ! pro u pu, while the program is typ e-checked using the assumptions p <: P pub ::

kind p and newP : pars p ! ob j u pu. This makes it p ossible for the implementation of derived

classes q :::r to access the protected metho ds of p and extend the implementation of p ob jects by

adding new metho ds or rede ning existing ones. Each of the subsequent class declaration clauses

are treated similarly so that, for example, the declaration of r has analogous access to the protected

metho ds of q . As in the pattern of abstype declarations given in Section 2.5, the client program

do es not have these capabilities.

Although wehave explained this construct under the assumption that q :::r are subtyp es of

p , they are more prop erly viewed as derived classes that mayormay not result in subtyp es. In

pub , for example, this could b e particular, since there is no restriction on the syntactic form of Q 10

an expression giving ob j u qu <: ob j u pu, or it might not. If it is not, then wehave the analog

of C private base classes where inheritance do es not pro duce a subtyp e.

4 Overview of soundness pro of

The soundness pro of, using the op erational semantics discussed in Section 3.2, has two parts. The

rst shows that evaluation preserves typ e; this prop erty is traditionally called sub ject reduction.

The second part established that no typable expression evaluates to error . In the second part,

we use a sp eci c evaluation strategy, describ ed in [FHM94], to carry out the argument. The two

parts together guarantee that we never obtain a \message-not-understo o d" errors from anytypable

expression.

While the details are di erent, the pro of follows the same outline as [FHM94, FM95]. A sketch

of the pro of app ears in App endix D.

eval

0 0

Theorem 4.1 Sub ject Reduction If e : is derivable, and e ! e , then e : is

` `

also derivable.

Theorem 4.2 Typ e Soundness If the judgement e : is derivable, then ev al e 6= error ,

where the function ev al is as in [FHM94], extended with rules for C l ass reduction.

5 Analysis

Here we brie y note several implications of our approach.

5.1 Representation indep endence for classes

One advantage of our decomp osition of classes into ob ject op erations and standard data abstraction

is that a numb er of prop erties develop ed in the analysis of traditional data abstraction without

ob jects may b e applied to ob ject-oriented languages. For example, the results in [Rey83, MM85,

Mit86, Mit91] givevarious sucient conditions on interchangeability of implementations. Put

brie y,wemay replace one implementation of a class with another, in any program, as long as the

protect and public interfaces of the new implementation conform to the old ones and the observable

b ehaviors corresp ond.

5.2 Subtyping and inheritance

A basic issue in the literature on ob ject-oriented programming is the relation b etween subtyping

and inheritance. An early and in uential pap er, [Sny86], argues that the way these two ideas are

often linked as in Ei el and C is inconvenient and unfounded. We b elieve that the arguments

in [Sny86, Co o92] and related pap ers are essentially correct for interface typ es: subtyping b etween

interface typ es has nothing to do with the way ob jects are implemented. However, the analysis in

the present pap er shows that for implementation typ es, inheritance may b e necessary although

not always sucient to pro duce a subtyp e. In short, if a typ e t is abstract, in the sense that all or

part of its implementation is hidden, then the only safe way to de ne a subtyp e of t is by extending

the hidden implementation. 11

5.3 \Private virtual" functions

There are some interesting problems asso ciated with C private virtual functions. In our

representation of classes, these show up immediately in the need to include \negative information"

in the interface of an abstract typ e. This is necessary if if wewant to b e able to extend the

representation, since otherwise we might try to add a new metho d that replaces an existing metho d,

invalidating another metho d that dep ends on the presence of the one that is replaced. See [FM94],

for example, for further discussion. However, this form of negative information is not used in

C class interfaces or header les. Therefore, wehave an anomalous situation in which private

virtual functions, which are not supp osed to b e visible to derived classes, can b e unintentionally

overridden b ecause in addition to b eing \private," they are also declared \virtual," which means

they are allowed to b e rede ned in derived classes.

6 Conclusion

In this pap er, we describ e a typ e-theoretic mo del of various levels of encapsulation and visibilityin

ob ject-oriented systems. More sp eci cally,we show that classes, of the form found in C , Ei el

and related languages, may b e regarded as the combination of two orthogonal language features:

a form of ob jects without encapsulation and a standard form of data abstraction mechanism al-

b eit higher-order and including subtyp e constraints. This intuitive view explains the correlation

between subtyping and inheritance and answers some of the criticism found in pap ers suchas

[Sny86, Co o92]; other advantages of our approach are outlined in Section 5.

Several other features of C -like ob ject systems can b e mo deled in our framework. In partic-

ular, we can account for friend functions, non-virtual functions and inheritance with private base

classes i.e., inheritance that do es not result in a subtyp e using the concepts presented here.

There are a numb er of promising directions for further work. One direction is to examine

further features of C , with the goal of identifying anomalies or simplifying the language. An

interesting topic in this vein is the incorp oration of \abstract" classes. An issue related to b oth

improving C -like systems and the general problem of name spaces for metho d names might

b e to develop a binding mechanism so that metho d names remain lo cal to their intended scop e.

This could resolve the problem with C private virtual functions and also simplify our typ e

system by eliminating the need for negative kind information in abstract typ e declarations. With

an eyetoward future language design, we also hop e to re ne the sp ecial syntax describ ed brie y in

Section 3.5 and consider the reformulation of our blo ck-structured constructs using mo dules and

dot notation [CL90, HL94]

References

[AC94a] M. Abadi and L. Cardelli. A theory of primitive ob jects: second-order systems. In Proc. European

Symposium on Programming, pages 1{24. Springer-Verlag, 1994.

[AC94b] M. Abadi and L. Cardelli. A theory of primitive ob jects: untyp ed and rst-order systems. In Proc.

Theor. Aspects of Computer Software, pages 296{320. Springer-Verlag LNCS 789, 1994.

[Bru93] K. Bruce. Safe typ e checking in a statically-typ ed ob ject-oriented programming language. In Proc

20th ACM Symp. Principles of Programming Languages, pages 285{298, 1993.

[CL90] Luca Cardelli and Xavier Leroy. Abstract typ es and the dot notation. Technical Rep ort 56, DEC

Systems Research Center, Palo Alto, CA, March 1990. 12

[Co o92] W.R. Co ok. Interfaces and sp eci cations for the Smalltalk-80 collection classes. In ACM Conf.

Object-orientedProgramming: Systems, Languages and Applications, pages 1{15, 1992.

[CW85] L. Cardelli and P.Wegner. On understanding typ es, data abstraction, and p olymorphism. Com-

puting Surveys, 174:471{522, 1985.

[ES90] M. Ellis and B. Stroustrop. The Annotated C Reference Manual. Addison-Wesley, 1990.

[FHM94] K. Fisher, F. Honsell, and J.C. Mitchell. A lamb da calculus of ob jects and metho d sp ecialization.

Nordic J. Computing formerly BIT, 1:3{37, 1994. Preliminary version app eared in Proc. IEEE

Symp. on Logic in Computer Science, 1993, 26{38.

[FM94] K. Fisher and J.C. Mitchell. Notes on typ ed ob ject-oriented programming. In Proc. Theoretical

Aspects of Computer Software, pages 844{885. Springer LNCS 789, 1994.

[FM95] K. Fisher and J. Mitchell. A delegation-based ob ject calculus with subtyping. In Fundamentals of

Computation Theory FCT'95. Springer LNCS, 1995. To app ear.

[GM94] C.A. Gunter and J.C. Mitchell, editors. Theoretical aspects of object-orientedprogramming. MIT

Press, Cambridge, MA, 1994.

[GR83] A. Goldb erg and D. Robson. Smal ltalk{80: The language and its implementation. Addison Wesley,

1983.

[HL94] Rob ert Harp er and Mark Lillibridge. A typ e-theoretic approach to higher-order mo dules with

sharing. In Proc. 21-st ACM Symp. on Principles of Programming Languages, 1994.

[Mey92] B. Meyer. Ei el: The Language. Prentice-Hall, 1992.

[Mit86] J.C. Mitchell. Representation indep endence and data abstraction. In Proc. 13th ACM Symp. on

Principles of Programming Languages, pages 263{276, January 1986.

[Mit91] J.C. Mitchell. On the equivalence of data representations. In V. Lifschitz, editor, Arti cial In-

tel ligence and Mathematical Theory of Computation: Papers in Honor of John McCarthy, pages

305{330. Academic Press, 1991.

[MM85] J.C. Mitchell and A.R. Meyer. Second-order logical relations. In Logics of Programs, pages 225{236,

Berlin, June 1985. Springer-Verlag LNCS 193.

[MP88] J.C. Mitchell and G.D. Plotkin. Abstract typ es have existential typ es. ACM Trans. on Program-

ming Languages and Systems, 103:470{502, 1988. Preliminary version app eared in Proc. 12th

ACM Symp. on Principles of Programming Languages, 1985.

[PT94] Benjamin C. Pierce and David N. Turner. Simple typ e-theoretic foundations for ob ject-oriented

programming. Journal of Functional Programming, 42:207{248, 1994.

[Rey83] J.C. Reynolds. Typ es, abstraction, and parametric p olymorphism. In Information Processing '83,

pages 513{523. North-Holland, Amsterdam, 1983.

[Sny86] A. Snyder. Encapsulation and inheritance in ob ject-oriented programming languages. In Proc.

ACM Symp. on Object-OrientedProgramming Systems, Languages, and Applications, pages 38{46,

Octob er 1986.

[Str86] B. Stroustrop. The C Programming Language. Addison-Wesley, 1986. 13

A Syntax and op erational semantics of expressions

Expressions

e :: = xjcj x: e j e e j

1 2

hi j e m jhe m = e ijhe + m = e ij

1 2 1 2

fjr<: R :: = R ;ejgj

1 2

Absty pe r <: R :: w ith x : ise in e

1 2

Op erational Semantics:

book

sw itch ext ov hhe m = e i+ m =e i ! hhe + m = e im =e i

1 2 2 3 3 1 3 3 2 2

book

per m ov ov hhe m = e im =e i ! hhe m =e im =e i

1 2 2 3 3 1 3 3 2 2

book

add ov he + m =e i ! hhe + m = e im =e i

1 2 2 1 2 2 2 2

book

cancel ov ov hhe m = e im =e i ! he m =e i

1 3 2 3 3 1 3 3

eval

x: e e ! [e =x]e

1 2 2 1

eval

he m= e im ! e he m=e i

1 2 2 1 2

where may either +or .

eval

Absty pe Absty pe r <: R :: w ith x : ! [R =r;e =x]e

1 2

is fjr<: R :: = R ;ejgin e

1 2

B Typ e System

Typ es

:: = j9r<: R ::

R j ob j t R :: = tj jpro t

1 2

Rows

R :: = r jhhiijhhRjm:iij t: R j R

Kinds

k ind :: = V j

V :: = ft g, b :: = +j jo

:: = T ! j , a :: = bj?

:: = M; V

M :: = fm~ g

Contexts

::= j;x: j;t : V j;r <: R ::

The judgement forms are:

well-formed context

e : term has typ e

: V well-formed typ e with variance V

R <: R row R subtyp e of R

1 2 1 2

B gives width vs. depth

<: typ e subtyp e of

1 2 1 2

R :: row has kind

The subtyping annotations are: 14

Width vs. Depth

B :: = wjdjw; d jB + B Indicate record subtyping forms.

1 2

\+" is the union of B and B .

1 2

Op erations on Variance Sets:

V V = set di erence

1 2

a a a

1 a 1 n

ft ;:::;t g, where a inverts the sign of a . ;:::;t g = ft

i i

1 1

D V ;:::;V = ftjt 2 V for some a,ig

1 n i

a if t 2 V

Vart; V =

? otherwise

Vart;V

V nt = V ft g

GV ar t; V ;:::;V = lubfVart; V ;:::;Vart; V g

1 n 1 n

GV ar t;V ;:::;V

1 n

M ergeV ;:::;V = ft j t 2 D V ;:::;V g

1 n 1 n

InvarV = ft j t 2 DV g

a a

V = ft j t 2 domg

where lub is taken with resp ect to the ordering: + o; o; ? ; ?+.

Variance Substitutions

0 0 +

M ergeV ;V if V = V ;t

2 1

1 1

0 0

M ergeV ; V if V = V ;t

2 1

1 1

[V =t]V =

2 1

0 0 o

M ergeV ; I nv ar V if V = V ;t

2 1

1 1

V if t 62 D V

1 1

Ordering on kinds:

V V i 8t; V ar t; V Vart; V

1 2 2 1

M ; V M ; V i M M and V V

1 1 2 2 1 2 1 2

a b

T ! T ! i b a and

1 2 1 2

C Typing rules

C.1 Context Rules

star t

t 62 dom

ty pe v ar

;t : ft g

` 15

R ::S ! M ; V

1 1 1 1

S ! M ; V S ! M ; V

0 0 0 1 1 1

DV dom

r 62 dom

row var

; r<: R ::S ! M ; V

1 0 0 0

: V

x 62 dom

exp v ar

;x:

; A

1 2

;a;

1 2

w eak ening

;a; A

1 2

where a :: = x: jt:V jr<: R ::

C.2 Rules for typ e expressions

t : ft g2

ty pe pr oj

t : ft g

: V

1 1

: V

2 2

ty pe ar r ow

: M ergeV ;V

1 2 1 2

;t : ft g R ::M; V

pr o

pro t R : InvarV n t

;t : ft g R ::M; V

Vart; V 2f+;?g

cov obj ect

ob j t R : V n t

;t : ft g R ::M; V

Vart; V 2fo; g

non cov obj ect

ob j t R : InvarV n t

;r <: R :: : V

= S ! M; V

exist

9r<: R :: : M ergeV ;V

1 2

w 16

C.3 Rules for rows

r<: R :: 2 dom

row proj

r ::

empty r ow

hhii ::M; ;

R ::S ! M; V

N M i 2f0;1g

r ow l abel

R ::S ! N; V

;t : ft g R ::M; V

r ow f n abs

Vart;V

t: R ::T ! M ; V nt

R ::T ! M; V

: V

r ow f n app cov

R ::M; M ergeV ;V

1 2

R ::T ! M; V

: V

r ow f n app contr a

R ::M; M ergeV ; V

1 2

R ::T ! M; V

: V

r ow f n app inv

R ::M; M ergeV ; I nv ar V

1 2

R ::T ! M; V

: V

row f n app vac

R ::M; V

R ::fm~;mg;V

: V

r ow ext

hhRjm : ii ::fm~g; M ergeV ;V

1 2 17

C.4 Subtyping rules for typ es

: V

<: ty pe r ef l

<:!

0 0

! !

1 2

;t : ft g R <: R

1 2

;t : ft g R ::M; V

Vart; V 2f?;+g

<:obj

prob j t R <: ob j t R

1 2

2 3

<: tr ans

1 3

C.5 Subtyping Rules for rows

R ::

<: r ow r ef l

R<: R

r<: R :: 2

r ow pr oj bound

r<: R

;t : ft g R <: R

1 2

;t : ft g R ::

t: R <: t: R

1 2

R <: R

1 2

R ::T !

: V

<: app cong

R <: R

1 2

R <: R

1 2

R ::T !

1 2

<:app cov

R <: R

1 1 2 2

B+d 18

R <: R

1 2

R ::T !

2 1

<: app contr a

R <: R

1 1 2 2

B+d

R <: R

1 2

R ::T !

: V : V

` `

1 1 2 2

<: app v ac

R <: R

1 1 2 2

R < : R : V

` `

1 2

hhR j m : ii :: i 2f1;2g

i i

<: cong

hhR jm:ii <: hhR jm:ii

1 2

R <: R <:

` `

1 2 1 2

hhR jm: ii :: i 2f1;2g

i i i

<:d

hhR jm: ii <: hhR jm: ii

1 1 2 2

B+d

R <: R

1 2

hhR jm:ii ::

<:w

hhR jm :ii <: R

1 2

B+w

R <: R

1 2

R R <:

3 2

<: tr ans

R R <:

3 1

B +B

Typ e and Row Equality Typeorrow expressions that di er only in names of b ound variables are consid-

ered identical. Additional equations b etween typ es and rows arise as a result of -reduction, written ! ,

or -conversion, written $ .

R ::; R ! R

row

R ::

: V; !

ty pe

: V

0 0

e : ; $ ; : V

` `

ty pe eq

e :

R <: t: R

1 2 2

<: r ig ht

R <: [ =t]R

1 2 2

t: R <: R

1 1 2

<: l ef t

[=t]R <: R

1 2

B 19

C.6 Rules for assigning typ es to terms

x : 2

exp pr oj

x :

e : ; < :

` `

1 1 2

subsumption

e :

;x: e :

1 2

exp abs

x: e :

1 2

e : e :

` `

1 1 2 2 1

exp app

e e :

1 2 2

empty pr o

hi : pro t hhii

e : pro t R

;t:ft g R ::fmg; V

;I e :[pro t r t=t]t r 62 V

r 2

pr o ext

he + m= e i : pro t hhR j m : ii

1 2

where I = r<: t:hhR j m : ii ::T ! ;; InvarV .

e : pro t R

;t:ft g R<: hhm:ii

;I e :[pro t r t=t]t

r 2

pr o ov er

he m= e i : pro t R

1 2

where I = r<: t: R ::T ! ;; InvarV .

e : prob j t R

;t:ft g R<: hhm:ii

pr obj

em :[prob j t R=t]

R ::

R <: R

e :[R =r ]

9 <: intr o

fjr<: R :: = R ;ejg:9r<: R ::

w w

e : 9r<: R ::

;r <: R ::; x : e :

: V

9 <: el im

Absty pe r < : R :: w ith x : ise in e :

1 2

w 20

D Overview of soundness pro of

We prove the soundness of our typ e system with resp ect to the op erational semantics given in Section 3.2.

We rst prove that evaluation preserves typ e; this prop erty is traditionally called sub ject reduction. We then

show that no typable expression evaluates to error using the evaluation rules given in [FHM94], extended

in a straightforward manner to account for the new encapsulation primitives. This fact guarantees that we

have no message-not-understo o d errors for expressions with pro typ es.

The pro of b egins with two lemmas ab out substitution for row and typ e variables. We then provea

normal form lemma that allows us to restrict our attention to derivations of a certain form, simplifying

later pro ofs. Lemmas D.5 and D.6 give us sub ject reduction for the b o okkeeping rules and -reduction,

resp ectively. Lemmas D.7, D.8, and D.9 imply sub ject reduction for -reduction, while Lemmas D.1 and

D.6 give us sub ject reduction for C l ass -reduction.

In the remainder of this section, we use meta-variable U to refer to either a rowortyp e expression,

meta-variable to refer to arbitrary kinds, and meta-judgement U : to indicate either \row has kind

"or\typ e is well-formed."

The rst two lemmas are substitution lemmas that are used to sp ecialize pro typ es to contain additional

metho ds and to proveC l ass reduction sound.

Lemma D.1 Row Substitution

0 0 0

A; R<: R; and R ::; If ;r<: R ::;

` ` `

0 0

then ; [R=r ] A ;

where

if A ; then A

if A U : ; then A [R=r ]U :

if A U <: U ; then A [R=r ]U < : [R=r ]U

1 2 1 2

B B

if A e : ; then A [R=r ]e :[R=r ]

Lemma D.2 Typ e Substitution If ;t : T; A and : V then

` `

if A ; then ; [ : V=t]

if A U : ; then ; [ : V=t] [=t]U :

if A U <: U ; then ; [ : V=t] [=t]U <: [=t]U

1 2 1 2

B B

The typ e and row equality rules intro duce many non-essential judgement derivations, which unnecessar-

ily complicate derivation analysis. We therefore restrict our attention to ` -derivations, whichwe de ne

as those derivations in which the only app earance of a typeorrow equality rule is as <:right immedi-

ately following an o ccurrence of a subtyping application rule <: app where the left-hand row function

expression is a rowvariable, or as ty pe eq immediately b efore an o ccurrence of 9 <: intr o . The nf of

atyp e or row expression is its normal form with resp ect to -reduction. The nf of a term expression e

is just e . Since we are only interested in typ es and rows in nf , the following lemma shows we can nd a

` -derivation for any judgementofinterest.

Lemma D.3 Normal Form for Derivations If A is derivable, then so is nf nfA.

` `

The pro of of this lemma is by induction on the derivation of A . Occurrences of equality rules may

b e eliminated in the ` -derivation b ecause tworowortyp e expressions related via -reduction must have

the same nf . The cases for the row application rules r ow f n app follows from the somewhat surprising

fact that if wemay derive that a normal-form row function t: R applied to a normal-form typ e is well-

formed, then wemay show that [=t]R is well-formed without using the row typing rule. The cases for

<: app are similar. 21

From this p oint on, we will only concern ourselves with contexts and typeorrow expressions that are

in nf . This limitation is not severe, since any term that has a typ e has a typ e in nf .Future analyses

of derivations will consider only ` -derivations, since its restriction on equality rules greatly simpli es the

pro ofs.

The following lemma is used to show that the sw itch ext ov reduction rule preserves typ es.

A and ;r <: t:hhR j m : ii ::T ! M ; V A are Lemma D.4 If ;p <: t: R ::T ! M ; V ;

` `

r p

w w

0 0

[r=p]A is both derivable, r 62 dom and M M , then ;r <: t:hhR j m : ii ::T ! M ; V ;[r=p]

p r r

also derivable, where A is any judgement not involving strictly -types.

The pro of of this lemma is very sensitive to the form of the pr o ext pro of rule.

eval

The next four lemmas show that the various comp onents of the ! relation preserve expression typ es.

book

Lemma D.5 is the rst of these, showing that the ! relation has the necessary prop erty.

book

0 0

Lemma D.5 If e : is derivable, and e ! e , then e : is derivable.

` `

The pro of of Lemma D.5 consists of two parts: the rst shows that a derivation from e : can only

e : and dep end on the form of , not on the form of e . More formally,if C[e]: is derived from

` `

0 0 0

e : is also derivable, then so is C [e ]: . This fact is easily seen by an insp ection of the typing

` `

book

rules. The second part shows that if e : is derivable, and e ! e by e matching the left-hand side of

book

one of the ! axioms, then e : is also derivable. This fact follows from a case analysis of the four

book

! axioms. Lemma D.4 is essential for the switch ext ov case.

The fact that -reduction preserves expression typ es is an immediate consequence of the following

lemma:

Lemma D.6 Expression Substitution If ;x : ; e : and e : areboth derivable, then

` `

1 2 2 1 1

so is ; [e =x]e : .

1 2 2

Lemma D.6 is proved by induction on the derivation of ;x : ; e : .

1 2 2

The next three lemmas together imply that -reduction preserves typ e. The rst is the key lemma in

showing sub ject reduction for messages sent to expressions with pro typ e. The second, which guarantees

that the variance annotations prop erly trackvariance, is essentially for showing the soundness of sealing ob j

typ es to pro typ es. The third implies sub ject reduction for expressions with ob j typ e.

Lemma D.7 Metho d Bo dies are Typ e Correct If he m = e i : pro t R is derivable in such

N 1 2

a way that the last rule in the derivation is not ty pe eq , then there exists a unique type such that

;t : ft g R<: hhm : ii and e :[pro t R=t]t areboth derivable. Furthermore, if =

` `

N N 2

then e : pro t R is also derivable.

N 1

Lemma D.8 If ;t : ft g; U <: U , U : , <: , and : V for i 2f1;2g

` ` ` `

N 1 2 N 2 2 N 1 2 N i i

are al l derivable, then

if Vart; =? then

; [ =t]U <: [ =t]U

N i 1 j 2

if Vart; =+ then

; [ =t]U <: [ =t]U

N 1 1 2 2

w;d

if Vart; = then

; [ =t]U <: [ =t]U

N 2 1 1 2

w;d

where isacontext listing only type variables.

Lemma D.9 Ob ject Typ es Come From Pro Typ es If he m = e i : ob j t R is derivable,

N 1 2

then there exists a type pro t R such that

he m = e i : pro t R

N 1 2

pro t R <: ob j t R

areboth derivable.

eval

0 0

Theorem D.10 Sub ject Reduction If e : is derivable, and e ! e , then e : is also deriv-

` `

able.

The pro of is similar in outline to that of Lemma D.5; it reduces to showing that each of the basic

book

evaluation steps preserves the typ e of the expression b eing reduced. The ! case follows from Lemma

D.5, the case from Lemma D.6, the case from Lemmas D.7, D.8, and D.9, and the C l ass case

from Lemmas D.1 and D.6.

Theorem D.11 Typ e Soundness If the judgement e : is derivable, then ev al e 6= error , where

the function ev al is as in [FHM94], extended with rules for C l ass reduction. 23