on type systems for object-oriented database programming...

On Type Systems for Object-Oriented DatabaseProgramming Languages

YURI LEONTIEV

Intuit Canada Limited

M. TAMER OZSU

University of Waterloo

AND

DUANE SZAFRON

University of Alberta

The concept of an object-oriented database programming language (OODBPL) isappealing because it has the potential of combining the advantages of object orientationand database programming to yield a powerful and universal programming languagedesign. A uniform and consistent combination of object orientation and databaseprogramming, however, is not straightforward. Since one of the main components of anobject-oriented programming language is its type system, one of the first problems thatarises during an OODBPL design is related to the development of a uniform, consistent,and theoretically sound type system that is sufficiently expressive to satisfy thecombined needs of object orientation and database programming.

The purpose of this article is to answer two questions: “What are the requirementsthat a modern type system for an object-oriented database programming languageshould satisfy?” and “Are there any type systems developed to-date that satisfy theserequirements?”. In order to answer the first question, we compile the set ofrequirements that an OODBPL type system should satisfy. We then use this set ofrequirements to evaluate more than 30 existing type systems. The result of thisextensive analysis shows that while each of the requirements is satisfied by at least onetype system, no type system satisfies all of them. It also enables identification of themechanisms that lie behind the strengths and weaknesses of the current type systems.

Categories and Subject Descriptors: D.3.2 [Programming Languages]: LanguageClassifications; D.3.3 [Programming Languages]: Language Constructs andFeatures; F.3.3 [Logics and Meanings of Programs]: Studies of Program Constructs;H.2.3 [Database Management]: Languages

General Terms: Design, Languages, Theory

Additional Key Words and Phrases: OODB, OODBPL, object-oriented databaseprogramming language, type checking, typing

Authors’ addresses: Y. Leontiev, Intuit Canada Limited, 7008 Roper Road, Edmonton, Alberta T6B 3H2,Canada; email: [email protected]; M. T. Ozsu, University of Waterloo, School of Computer Science, Waterloo,Ontario N2L 3G1, Canada; email: [email protected]; D. Szafron, University of Alberta, Department ofComputing Science, Edmonton, Alberta T6G 2H1, Canada; email: [email protected] to make digital or hard copies of part or all of this work for personal or classroom use is grantedwithout fee provided that copies are not made or distributed for profit or direct commercial advantage andthat copies show this notice on the first page or initial screen of a display along with the full citation.Copyrights for components of this work owned by others than ACM must be honored. Abstracting withcredit is permitted. To copy otherwise, to republish, to post on servers, to redistribute to lists, or to use anycomponent of this work in other works requires prior specific permission and/or a fee. Permissions may berequested from Publications Dept., ACM, Inc., 1515 Broadway, New York, NY 10036 USA, fax: +1 (212)869-0481, or [email protected]©2002 ACM 0360-0300/02/1200-0409 $5.00

ACM Computing Surveys, Vol. 34, No. 4, December 2002, pp. 409–449.

410 Y. Leontiev et al.

1. INTRODUCTION

From its early days, object orientation(OO) was considered to be one of themost influential and useful programmingparadigms. Its impact on research in vir-tually all areas of computing science canonly be compared to that of relational alge-bra, or that of the functional and logic pro-gramming paradigms. Much of the powerof object orientation lies in the fact thatit provides conceptual and modeling capa-bilities that allow it to express real-worldentities with relative simplicity. Anothersource of the appeal of object orientation isits support for incremental software con-struction, provided in the form of codereuse.

Object-oriented database programminglanguages (OODBPLs) have the potentialto combine, in a single uniform frame-work, the modeling and software con-struction power of the object-orientedparadigm, extensive and efficient datastorage and retrieval techniques of mod-ern database systems, and the effi-ciency and power of today’s programminglanguages.

Both the modeling and software con-struction powers of object-oriented lan-guages are rooted in their type and inher-itance systems. A properly designed, rich,and theoretically sound type system cangreatly increase the power of a language,while a poor, inflexible type system canrender almost all power inherent in theobject-oriented paradigm useless.

While the type system of an object-oriented language greatly affects its char-acteristics, the type system of an OODBPLaffects its characteristics even more.The reason is the presence of differ-ent and sometimes contradictory require-ments that are imposed on the type systemby an OODBPL’s database and program-ming language components.

The purpose of this article is to an-swer two key questions: “What are the re-quirements that a modern type system foran object-oriented database programminglanguage should satisfy?” and “Are thereany type systems developed to-date thatsatisfy these requirements?”

In order to answer the first question,the set of requirements put forth in theliterature for type systems (Section 2.2),modern object-oriented programming lan-guages (Section 2.3), database program-ming languages (Section 2.4), and object-oriented database systems (Section 2.5)is considered to yield a set of requiredtype system features. The resulting com-bination of requirements is presented inSection 2.6. Section 2.7 presents the testsuite that is used to evaluate the existingtype systems reviewed in this article.

Section 3 presents an extensive reviewof more than 30 languages and type sys-tems. These type systems are evaluatedwith respect to the requirements and thetest suite presented in Section 2.6. The re-sult of this extensive analysis (presentedin Section 4) shows that while each of therequirements is satisfied by at least onetype system, no type system satisfies allof them. Section 4 also identifies the mech-anisms that lie behind the strengths andweaknesses of the current type systems.The knowledge obtained this way can beused to aid in the design and develop-ment of a type system that satisfies allof the above requirements (e.g., Leontiev[1999]), even though a new language de-sign is not the focus of this article.

2. TYPE SYSTEM REQUIREMENTS

2.1. Terminology

We start by establishing some terminol-ogy to be used throughout the rest of thisarticle. This is necessary as many of theterms used in the object-oriented languageresearch area have no clear definition andare used differently by different authors.We note that this is not a tutorial on object-oriented concepts, but only a consistentset of definitions (even if they are not uni-versally accepted) that we use throughoutthis article. Most of the terminology belowcomes from Cardelli [1989] and Black andPalsberg [1994].

Object. A primitive term for a dataitem used to model a concept or a real-world entity.

ACM Computing Surveys, Vol. 34, No. 4, December 2002.

On Type Systems for Object-Oriented Database Programming Languages 411

Method. A procedure to be executedwhen an object is sent an appropriatemessage.

Message. A part f of an invocationx. f , where x is an object; an identificationfor a related set of methods.

Function Name. A part f of invoca-tion f (x); also can be termed as a messagenot associated with any type. Sometimescalled a free-floating function.

Function. A procedure to be executedwhen a function invocation is requested.Function relates to a function name thesame way a method relates to a message.

Interface Type. A description of mes-sages applicable to an object.

Implementation (Representation) Type.A description of an object’s structure.

Type. A shorthand for interface or im-plementation type or both, depending onthe context.

Mutable Object Type. A type of an ob-ject that is capable of changing its state atrun-time. For example, variables and ar-rays are mutable objects. These types aresometimes called imperative types.

Parametric (Parameterized) Type (Mes-sage, Function). A type (message, func-tion) that describes a family of types (mes-sages, functions) by using (an) explicit pa-rameter(s). For example,

type T_List(X) {

getAt(T_Integer): X;

};

Constrained Type. A parametric typethat places a constraint on its parame-ter(s). The mechanism that allows a pro-grammer to specify such a type is calledbounded quantification. For example:

type T_PersonList(X)

where X subtype of T_Person;

specifies a constrained parametric typeT PersonList.

Intersection (Greatest Lower Bound)Types. An intersection of a set of types isa type that represents the greatest lower

bound of the set in the type lattice. Inter-section types are useful for typing of set-theoretic operations and queries.

Union (Lowest Upper Bound) Types. Aunion of a set of types is a type that repre-sents the lowest upper bound of the set inthe type lattice. Union types are useful fortyping of set-theoretic operations, queries,and conditionals.

Inheritance. A mechanism for makingone (interface or implementation) typefrom another. A single inheritance re-quires that a type has at most one im-mediate ancestor (parent) in the inheri-tance chain; multiple inheritance lifts thisrestriction.

Interface Subtyping. A partial order oninterface types. An interface type A is asubtype of another interface type B whenan object of the interface type B can bethought of as an object of the interfacetype A (e.g., a type T Student is a sub-type of T Person since every student canbe thought of as a person).

Implementation Subtyping (CodeReuse). A partial order on implemen-tation types. An implementation type Ais a subtype of another implementationtype B if it is possible to use code writtenfor B to manipulate objects that have theimplementation type A.

Structural Subtyping. Subtypingautomatically determined by objectstructure. Sometimes termed as implicitsubtyping. Its opposite, explicit or user-definable subtyping, relies on user-supplied subtyping clauses to determinethe subtyping relationship between types.

First-Class Object. An object that is ca-pable of receiving messages.

Non-First-Class Object (Value). An im-mutable object that lacks the ability toreceive messages. Traditionally, it is as-sumed that values have no interface, justa set of operations defined on them. In thisarticle, such a set of operations will be con-sidered an interface of a value.

Primitive (Atomic) Type. A primitivetype is a type of basic (primitive)



system-defined objects or values (such asintegers, reals, characters, etc.). Primitivetypes usually have a special status in non-uniform systems and languages.

Soundness of a Type System. Inabilityof a successfully typechecked program toproduce run-time type errors. Sometimesdivided into static and dynamic sound-ness. Dynamic soundness is weaker thanstatic soundness. It makes sense for lan-guages with dynamic type checking andassures that run-time type errors will becaught.

Verifiability of a Type System (Decid-able Typechecking). The ability to verifythat a program does not contain type er-rors with respect to a particular type sys-tem; equivalently, the presence of a de-cidable typechecking algorithm. Note thatverifiability does not imply soundness.For example, the language Eiffel [Meyer1988] has a decidable typechecking al-gorithm, but a successfully typecheckedprogram can produce run-time typeerrors.

Substitutability. A property of a typesystem (language) that guarantees that anobject of a subtype can be used everywherethe object of its supertype can (e.g., if atype T Person is a supertype of T Student,then a student can be legally used wher-ever a person can be).

Dispatch. A process of finding out atrun-time which method of a particularmessage to execute. Single dispatch basesits decision on the type of the first argu-ment (receiver) only, while multiple dis-patch. takes into account types of other ar-guments as well. The term static dispatchwill be used to refer to a compile-time pro-cess of method determination.

Static/Dynamic Typing (Typechecking).Static typechecking is done at compile-time, while dynamic typechecking is doneat run-time.

Implicit/Explicit Typing. Languageswith explicit typing require the program-mer to insert type annotations in theprogram. Languages with implicit typinginfer the types of expressions without any

help from the programmer. Intermediateapproaches are also possible.

Inclusion Polymorphism. This termrefers to a combination of subtyping andsubstitutability. Inclusion polymorphismallows an object to be viewed as belong-ing to many different types that need notbe disjoint; that is, there may be inclusionof types.

Parametric Polymorphism. Paramet-ric polymorphism is present when para-metric specifications (e.g., parametrictypes) are supported. This kind of poly-morphism allows for specifications thattake types as parameters.

Covariance (Contravariance, Novari-ance). Covariance means that changes ina particular type are parallel to the di-rection of the type hierarchy. In the fol-lowing example the result type of themethod getAt changes covariantly, as it isT Person in Definition 1 (which occurs inthe type T PersonList) and T Student (asubtype of T Person) in Definition 2 (whichoccurs in the type T StudentList, a sub-type of T PersonList).

type T_Student subtype of T_Person;

type T_PersonList {

getAt(T_Integer): T_Person; // 1

};

type T_StudentList subtype

of T_PersonList {

getAt(T_Integer): T_Student; // 2

};

The reverse direction is termed as con-travariant. Novariance forbids any typechanges along the type hierarchy. In thisexample, the argument type T Integerchanges novariantly, that is, does notchange at all.

The terms class and subclassing aredeliberately avoided in this paper as theyare too overloaded. In object-oriented lit-erature, the term class is used to denotea mechanism for object construction, anequivalent of an implementation type, anequivalent of an interface type, a set of



objects satisfying a particular condition,or some combination of the above fournotions. The definition of subclassing isequally overloaded.

Also, the term type is qualified as be-ing either interface type or implementa-tion type. This will prove useful when con-sidering type systems where the two typenotions are distinct.

2.2. Essential Features of a Type System

The major goals of a type system in today’sprogramming languages and databasesystems include [Cardelli 1989, 1997,Black and Palsberg 1994]:

(1) Provide a programmer with an effi-cient way of catching programming er-rors before a program (or a part of it) isactually executed. This is often consid-ered to be the major objective of a typesystem in the programming languagecommunity.

(2) Serve as a data structuring tool for de-sign and modeling purposes. Many de-sign technologies that have emergedthrough the past decade rely partiallyor fully on type systems to providea convenient design and documenta-tion framework for a system develop-ment process. This is especially trueof object-oriented design technologies.This property is often considered to bethe major goal of a type system in thedatabase community.

(3) Provide a convenient framework forprogram maintenance. This includesdocumentation at the production stageof program evolution as well as theability of a programmer to understandthe functionality and interfaces of acompleted product.

(4) Provide sufficient information for op-timization purposes. The informationprovided by the type system can beused by an optimizing compiler, inter-preter, or a query optimizer (in persis-tent systems) to improve the efficiencyof a program.

In order for a compiler (or interpreter) tobe able to typecheck a program (or a part

of it), there must exist a typechecking algo-rithm. Existence of such an algorithm fora given type system is termed as verifia-bility of the type system [Cardelli 1997].Thus, a type system should be verifiable.It is preferable that a type system shouldbe decidably verifiable; however, one mayhave to put up with an undecidable typesystem just as one puts up with un-decidable programs if enough expressivepower is desired [Black and Palsberg1994]. The verifiability property also im-plies that a type system should be prov-ably sound, i.e. there should exist a formalproof that a successfully type-checked pro-gram does not generate any type errors atrun-time.

If a compiler finds a type error and re-ports it to a programmer, the latter shouldhave sufficient information to be able tounderstand the reason for the type errorin order to correct it. Thus, the type sys-tem should be transparent.

A type system should also be enforceablein order to prevent an execution of type-incorrect programs. This implies that pro-grams have to be written with as muchtype information as possible to prevent“false alarms.”

Finally, a type system should be exten-sible. This requirement stems from thefact that none of the existing type systemswere found to be satisfactory for all pos-sible applications. Therefore, the chancethat any new type system will satisfy allapplication domains is remote. If a typesystem can not be extended, it will sooneror later be abandoned for a type systemthat can adapt to new application require-ments. Switching from one type system toanother is extremely costly both in termsof people resources (that have to be reed-ucated) and in terms of data conversioncosts.

2.3. Object-Oriented ProgrammingLanguage Requirements

Pure object-oriented programming lan-guages pose some specific requirementson their type systems. These require-ments will be constructed by consideringfeatures essential for pure object-oriented



languages and reformulating them interms of type system features.

For a language to be called a pureobject-oriented language, it should pos-sess at least the following properties, someof which are often claimed as absolutelynecessary for future object-oriented lan-guages [Tsichritzis et al. 1992]:

(1) Encapsulation. This property is usu-ally considered as one of the char-acteristic features of object-orientedlanguages and greatly facilitates codereuse. It refers to the ability of alanguage to shield internals of anobject implementation from outsideaccess.

(2) Inheritance. This is a characteristicproperty of object-oriented languagesas well. The inheritance mechanismpromotes and facilitates well-structu-red software design and reusabilityof the code. Multiple inheritance ishighly desirable, as its absence leadsto clumsy or limited type specificationin some important cases.

(3) Uniformity. Primitive values (inte-gers etc.), types, and messages (meth-ods) should be first-class objects. Ifthis requirement is not satisfied, thelanguage will have to handle thenon-object entities in some non-object-oriented way, and will therefore notbe purely object-oriented. Note thatthe existence of methods that areable to operate on types and othermethods is a consequence of thisproperty. This is also advocated inHauck [1993].

(4) Object access and manipulation uni-formity. An object can only be ma-nipulated by methods defined for it.Together with uniformity, this prop-erty provides for purely object-orientedprogramming.

(5) Method uniformity. This refers to theabsence of distinction between storedand computed methods or, equiva-lently, the absence of public instancevariables. This requirement is impor-tant as its violation breaks encapsu-lation and may effectively hinder the

usefulness of the code reusability pro-vided by inheritance.

(6) Separation between interface and im-plementation inheritance (sometimestermed as separation between typeand class hierarchies). This is ac-tually a consequence of encapsula-tion, inheritance, and object manipula-tion uniformity. Additional argumentsin favor of such separation can befound in LaLonde and Pugh [1991],Castagna [1996], Taivalsaari [1996],Baumgartner et al. [1996], Leontievet al. [1998].

(7) Multi-methods (multiple dispatch).This refers to the ability of a languageto use types of all arguments duringdispatch. Traditionally, only the typeof the first argument (the receiver) isused. This property of the language isessential to adequately model binarymethods [Bruce et al. 1996a; Castagna1996; Leavens and Millstein 1998;Fisher and Mitchell 1996] and cer-tain object-oriented design patterns[Baumgartner et al. 1996].

Using these requirements for pure object-oriented languages, it is now possible toformulate desirable features of type sys-tems for such languages. These require-ments are:

(1) Inheritance mechanisms for both in-terface and implementation inheri-tance. This requirement is a directconsequence of the language require-ments 2 and 6 above.

(2) Type system reflexivity. This is nec-essary to ensure uniformity of thelanguage (requirement 3), since types(classes) have to be objects.1 Since ev-ery object has a type, types and classesneed to have types as well. Thus, thetype system needs to be reflexive.

(3) Method types. This is also a con-sequence of uniformity. Indeed, sincemethods have to be objects to ensureuniformity, they will have types. More-over, when methods are manipulated

1 The term “type system closure” is sometimes usedto denote this property.



as objects (e.g., passed as argumentsto other methods), their types shouldbe descriptive enough to ensure the va-lidity of type-checking.

(4) Method uniformity at the type level(no distinction between types of storedand computed methods). This is a di-rect consequence of the language re-quirement 5.

(5) Support for multi-methods (multipledispatch). This is a consequence ofthe language requirement 7.

(6) Substitutability (at least for interfaceinheritance). This property is essen-tial to support extensibility and inclu-sion polymorphism. The latter is usedto achieve one of the primary goalsof the object-oriented paradigm: codereuse.

2.4. Database Programming LanguageRequirements

Database programming languages(DBPLs) possess their own set of distin-guishing features that poses additionalrequirements on type systems. The ap-proach of the previous section will be usedto derive the type system features fromthe following list of necessary featuresof a persistent language that is taken2

from Atkinson and Buneman [1987] andAtkinson and Morrison [1995].

(1) Persistence independence (the form ofthe program is independent of thelongevity of data the program op-erates upon). This is necessary toprovide seamless integration betweenthe database and the language andto significantly reduce the amount ofcode necessary to deal with persistentdata.

(2) Orthogonality of type and persistence(data of all types can be persistentas well as transient). This is an aidto data modeling as it ensures thatthe model can be independent of thelongevity of data. It also eliminates the

2 Features not related to type system are droppedfrom the list.

need of explicit persistent-to-transientdata conversions.

(3) User-defined type constructors. Thisrequirement is due to the necessityof modeling new, potentially complexdata structures in a uniform and con-sistent manner.

(4) Information hiding (also known asencapsulation). Encapsulation al-lows for data modeling at a higher(more abstract) level as it hides theimplementation details and givesthe programmer an ability to dealwith abstract interfaces rather thanconcrete data structures. It greatlyfacilitates modeling, code reuse, andcomponent integration.

(5) Polymorphism (parametric, inclusion,or both). Parametric and inclusionpolymorphisms make the specifica-tions more succinct and precise. Theyalso allow for a significant reductionin the amount of code that needs to bewritten to specify and implement a par-ticular data model, as a significant por-tion of the specifications are reused viagenericity achieved by the use of poly-morphic constructs.

(6) Static and strong typing with pro-visions for partial-type specification(which necessitates the presence of atype mechanism similar to one formedby type constructor dynamic and oper-ator typecase). This is necessary in or-der to deal with data that come froma persistent store whose structure isonly partially known at the time theprogram is written. An example of aprogram that requires such capabili-ties is a generic database browser thatis supposed to work on any databaseindependently of its structure.

(7) Incremental program construction andmodularity. This principle ensuresthat most of the program modificationscan be done locally, without affectingthe rest of the code. While this prop-erty is very important for program-ming languages in general, it is evenmore important for database program-ming, since databases tend to exist andevolve for extensive periods of time. As



a database evolves, the programs de-signed to operate on it have to evolveas well. Modularity is one of the majorfeatures that significantly reduce theoverhead of such an evolution.

(8) Query facilities. One of the main rea-sons behind the success of the rela-tional data model was its ability tosupport declarative, simple, yet pow-erful data access/query languages. Inorder for object systems to be success-ful, they must provide querying capa-bilities equal or exceeding those of therelational systems.

(9) Ability of a program to deal with statechange. This requirement is neces-sary as persistent data outlive the pro-gram and if a program is not able tochange data, the state of persistentdata will never change.

From this list of requirements, the fol-lowing properties of the type system canbe derived:

(1) Types (classes) in the type systemshould not be specified as either per-sistent or transient. This is the DBPLrequirement 2 reformulated in termsof type system terminology.

(2) User-defined type constructors. Thisis the same as the DBPL require-ment 3.

(3) Encapsulation. This follows from theDBPL requirement 4.

(4) The presence of parametric types.This follows from the DBPL require-ments 5 (parametric polymorphism)and 3. It is also desirable to han-dle bounded (constrained) paramet-ric types as it increases the modelingpower of the type system.

(5) Possibility of partial type specificationand dynamic type checking. This fol-lows from the DBPL requirement 6.

(6) Verifiable and sound type system (asa consequence of the DBPL require-ment 6).

(7) Incremental type checking (as a con-sequence of the DBPL modularity re-quirement).

(8) The ability of the type system to cor-rectly type declarative queries. Thisstems from the DBPL requirement 8.According to Buneman and Pierce[1999], this requires that the type sys-tem can support union (least upperbound) types.

(9) The ability of the type system to dealwith types of mutable objects (later re-ferred to as mutable object types) andassignment. This is a direct conse-quence of the DBPL requirement 9.

In addition to the above, Kirby et al.[1996] advocates the use of reflection inpersistent object systems.

The combination of object-orientednessand persistence poses some additional re-quirements described in the next section.

2.5. Object-Oriented Database SystemRequirements

A list of features needed or desirablein object-oriented database managementsystems (OODBMS) and the rationale be-hind it are given in Atkinson et al. [1992].This is the most comprehensive of suchlists published so far. The following list3

is the part of it that is related to type sys-tem issues. It contains additional require-ments to those already listed in the previ-ous sections.

(1) Complex objects (orthogonal type con-structors should include at least sets,tuples, and lists). This is necessary toensure that the modeling power of thesystem is sufficient to deal with mod-ern applications, such as CAD/CAM,medical and geographical informationsystems.

(2) Extensibility. User-defined and sys-tem types should have the same sta-tus and the user should be able to addnew “primitive” types to the system.

3 Some issues often considered as deficiencies ofobject-oriented systems (for example, in Kim [1993])but deemed optional in Atkinson et al. [1992] arelisted here as mandatory. The reason for that is theunderstanding that if object-oriented databases areto be the next step in the database development, theyshould utilize the advances already made in rela-tional databases.



This is also due to the necessity of deal-ing with new demanding applicationareas. It is impossible to anticipate allthe data types that will be requiredto model the data structures in thoseareas since some of them are yet toemerge. By providing the same statusto system and user-defined types, thesystem guarantees that its capabilitiesare not decreased when it is applied toa new application domain. Extensibil-ity is also advocated in Matthes andSchmidt [1991].

(3) Views. A view is, in a sense, an abil-ity to transparently change the ap-pearance of data for different users(clients). The importance of this con-cept as well as its usefulness and powerhave been convincingly demonstratedby years of experience with relationaldatabases.

(4) Dynamic schema evolution. This re-quirement is based on the necessityto maintain (and change) the databasestructure over extensive periods oftime. While it is sometimes possible tocreate a completely new database witha new schema and migrate data to it,this approach is usually quite expen-sive and results in a substantial downtime, which may not be acceptable inlarge distributed applications such ashospital or banking systems. Dynamicschema evolution makes it possible tochange a database structure transpar-ently to its users.

These additional requirements have tobe taken into account when designing atype system for a pure object-orienteddatabase programming language. Next,the requirement summary will be pre-sented and a short overview will be given.

2.6. Summary of Requirements

The following is the compilation of all typesystem requirements presented so far. Thecategorization of the requirements pre-sented here is subjective, but it does pro-vide a useful structure to the extensive setof requirements compiled so far. Each re-

quirement listed below contains a refer-ence to the section where it has been in-troduced and explained.

(1) Theoretical requirements(a) Verifiability (preferably decidable)

and provable soundness of the typesystem. These features are neces-sary for the type system to be use-ful for program verification (seeSection 2.2 and Section 2.4).

(2) Inheritance requirements

(a) Inheritance mechanisms for bothinterface and implementation in-heritance (Section 2.3).

(b) Substitutability property (atleast for interface inheritance)(Section 2.3).

(3) Expressibility requirements

(a) Method types (Section 2.3).(b) Parametric types (Section 2.4).(c) Orthogonal type constructors

(at least sets, tuples, and lists)(Section 2.4).

(d) Encapsulation (Section 2.3 andSection 2.4).

(e) The ability of the type system todeal with mutable object types andassignment (Section 2.4).

(f) The ability of the type systemto correctly type multi-methods(Section 2.3).

(g) The ability of the type systemto correctly type SQL-like queries(Section 2.4).

(4) Uniformity requirements(a) Extensibility (user-defined and sys-

tem types should have the samestatus) (Section 2.5).

(b) Types (classes) in the type sys-tem should not be specified as ei-ther persistent or transient (Sec-tion 2.4).

(c) Method uniformity at the typelevel (no distinction between typesof stored and computed methods)(Section 2.3).

(5) Reflexivity requirements(a) Type system reflexivity (Sec-

tion 2.3).



(6) Dynamic requirements

(a) Possibility of partial type specifi-cation and dynamic type checking(Section 2.4).

(b) Provisions for schema evolution(Section 2.5).

(7) Other requirements

(a) Transparency of the type system fora programmer (Section 2.2).

(b) Incremental type checking(Section 2.4).

(c) The ability to define views in a type-safe fashion (Section 2.5).

Some of the above requirements arecomplementary, while others are contra-dictory. Most notably, decidable verifica-tion conflicts with reflection (as shown,for example, in Cardelli [1986]). Also, en-forceability conflicts (to a degree) with par-tial type specification. Another conflict isthat the complexity of the type systemthat satisfies the expressibility require-ments will most probably make the result-ing type system much less transparent fora programmer than one would like it tobe. Connor et al. [1991] also identified aconflict between substitutability, mutabletypes, and static type safety. The presenceof such contradictory requirements makesthe task of designing a type system thatsatisfies them particularly difficult.

2.7. Test Programs

The following is a set of test programsthat a type system should be able to typecorrectly.4 These tests are primarily de-signed to test type systems for their ex-pressibility as this is the most difficult setof requirements to check; however, the lasttest is the test for reflexivity and unifor-mity. The example programs are writtenin an object-oriented pseudo-language andare used to illustrate the tests rather thanto suggest specific language constructs.

These programs are designed to testknown problem areas of object-oriented

4 Note that the terms “test” and “test program” arenot used here in the traditional software engineer-ing sense. Our tests are actually benchmarks thatvalidate expressive power.

type systems. They are also used to ver-ify the ability of the type system to con-sistently and orthogonally combine para-metric and inclusion polymorphism withmutable types and assignment. This hasto be done because soundness, verifiability,parametricity, substitutability, and muta-ble types are all among the requirementsfor an OODBPL type system.

Many of the expressibility tests areadapted from Black and Palsberg [1994],which presented a benchmark for test-ing type system expressibility. However,their benchmark was designed to mea-sure the expressibility of a type system foran object-oriented programming languageand not for an object-oriented databaseprogramming language. Thus, some testsrelated to the additional expressibil-ity requirements presented above wereadded.

The requirement related to mutable ob-ject types and assignment is probed byeach of the tests below. This is done in or-der to verify that a type system can dealwith mutable types in combination withparametric and inclusion polymorphisms–a well-known problem area in object-oriented type systems [Connor et al. 1991].

(1) Types T Person and T Childwith method getAge that returnsT Integer when applied to a personand T SmallInteger when applied toa child. (PERSON )

type T_Integer;

type T_SmallInteger subtype of

T_Integer;

type T_Person {

getAge(): T_Integer;

};

type T_Child subtype of T_Person {

getAge(): T_SmallInteger;

};

T_Person p := new T_Person (...);

T_Child c := new T_Child (...);

T_Integer i;

T_SmallInteger si;

i := p.getAge(); // should be Ok

i := c.getAge(); // should be Ok



si := p.getAge(); // should cause

// compile-time error

si := c.getAge(); // should be Ok

This test is designed to verify thatsubtyping does not necessitate theabsence of changes. Surprisingly,there are a considerable number oflanguages that do not allow anychanges while inheriting, only ad-ditions. This significantly limits thepower of the type system and forcesthe designer to use less specific typeinformation.

(2) Types T Point and T ColorPoint,with equality on both. The equal-ity between color points should takecolor into account, while the equal-ity between two points or betweena point and a color point shouldignore it. (POINT)type T_Point {

equal(T_Point p):T_Bool

implementation ... ;

// equal1

};

type T_ColorPoint subtype of

T_Point {

equal(T_ColorPoint p):T_Bool


// equal2

};

T_Point p1 := new T_Point (...);

T_ColorPoint p2 := new

T_ColorPoint (...);

p1.equal(p1); // should call equal1




p1 := new T_ColorPoint (...);





This test is adapted from Black andPalsberg [1994]. It tests the type sys-tem’s ability to deal with binary meth-ods, a well-known problem area inobject-oriented type systems [Bruce

et al. 1996a; Fisher and Mitchell1996].

(3) Types T Number (with unrelated sub-types T Real and T Radix) and T Datewith comparison methods such thatcomparing two numbers or two datesis legal, while their cross-comparisonis not. All method code below, ex-cept for the code for the method less,should be reused. (COMPARABLE)

interface I_Comparable {

less(selftype c):T_Bool;

greater(selftype c):T_Bool

implementation { return

c.less(this); };

};

type T_Number implements

I_Comparable {less(T_Number n):

T_Bool implementation ... ;

// less1

};

type T_Real subtype of

T_Number { ... };

type T_Radix subtype of

T_Number { ... };

type T_Date implements I_Comparable

{ less(T_Date d):T_Bool

implementation ... ; // less2

};

T_Date d1, d2;

T_Number n1, n2;

T_Radix radixVar := 0xF;

T_Real realVar := 1.0;

d1 := ’2/3/99’; d2 := ’3/4/78’;

n1 := realVar;

n2 := radixVar;

n1.less(n2); // should call

// less1n2.greater(n1); // should

// eventually call less1

n1.less(realVar); // should call

// less1

n2.greater(radixVar); // should


d1.less(d2); // should call

// less2



d1.greater(d2); // should


d1.less(n1); // should cause


n1.less(d1); // should cause


This is an additional test for binarymethod handling. It tests whether thesubsumption property can be main-tained in the presence of binary meth-ods. This test is necessary due to thefact that some approaches to the bi-nary method problem (most notably,matching [Bruce et al. 1995, 1996b]abandon substitutability, which isone of the requirements for anOODBPL type system.

(4) A parametric input/output/IOstreamtype hierarchy such that the threetypes are parameterized by the typeof objects readable/writable to/froma particular stream, with T IOstreambeing a subtype of both input and out-put stream types. (STREAMS)

type T_InputStream(covar X) {

get():X;

isEmpty():T_Bool;

};

type T_OutputStream(contravar X) {

put(X arg);

};

type T_IOStream(novar X)

subtype of T_InputStream(X),

T_OutputStream(X);

type T_Point { ... };

type T_ColorPoint subtype of

T_Point { ... };

T_Point p := new T_Point (...);

T_ColorPoint cp := new

T_ColorPoint (...);

T_InputStream(T_Point) isp;

T_OutputStream(T_Point) osp;

T_IOStream(T_Point) iosp;

T_InputStream(T_ColorPoint) iscp;

T_OutputStream(T_ColorPoint) oscp;

T_IOStream(T_ColorPoint) ioscp;

... // Initialization of the

// above streams

p := isp.get(); // should be Ok

p := iscp.get(); // should be Ok

cp := isp.get(); // should cause


cp := iscp.get(); // should be Ok

osp.put(p); // should be Ok

oscp.put(p); // should cause


osp.put(cp); // should be Ok

oscp.put(cp); // should be Ok

isp := iosp; // should be Ok

isp := ioscp; // should be Ok

iscp := iosp; // should cause


iscp := ioscp; // should be Ok

osp := iosp; // should be Ok

osp := ioscp; // should cause


oscp := iosp; // should be Ok

oscp := ioscp; // should be Ok

This test is designed to verify thata combination of parametric and in-clusion polymorphism in the typesystem does not adversely affect ei-ther of them. In other words, it teststhe orthogonality of the two poly-morphisms. The presence of bothparametricity and inclusion polymor-phism (subtyping + substitutability)in the type system is among therequirements compiled earlier. Theunrestricted combination of the twopolymorphisms is known to be diffi-cult [Day et al. 1995; Bracha et al.1998c].

(5) Sorting of arbitrary objects under theconstraint that all the objects have acomparison method. (SORT)

interface I_Comparable {

less(selftype c):T_Bool;

};

type T_Number implements

I_Comparable { ... };

type T_Person { ... };



type T_List(novar X) { ... };

sort(T_List(X) list): T_List(X)

where (X implements I_Comparable)


T_List(T_Number) ln;

T_List(T_Person) lp;

... // Initialization of list

// variables

ln := sort(ln); // should be Ok

lp := sort(lp); // should cause


lp := sort(ln); // should cause


ln := sort(lp); // should cause


This test is due to Black andPalsberg [1994]. It is designed to ver-ify the ability of the type system todeal with bounded quantification ofthe form “for all types satisfying agiven condition”. This is yet anotheraspect of the binary method problem.It also tests the ability of the type sys-tem to provide a link between para-metricity and subtyping.

(6) Generic sort with a comparisonmethod (<) as a parameter. Thegeneric sort can be applied to a setof any objects provided that an ap-propriate comparison method is sup-plied. (GENSORT)

type T_List(X) { ... };

type T_Number {

less(T_Number arg):T_Bool;

};

type T_Date {

compare(T_Date arg):T_Bool;

};

sort(T_List(X) list, (X,X):

T_Bool comparison): T_List(X)


T_List(Number) ln;

T_List(Date) ld;

... // Initialization of list

// variables

ln := sort(ln,less); // should

// be Ok

ld := sort(ld,compare); // should

// be Ok

ln := sort(ld,compare); // should

// cause compile-time error

ln := sort(ln,compare); // should


This test is also from Black andPalsberg [1994]. It is designed to ver-ify that the type system is capableof combining parametricity, methodtyping, and substitutability.

(7) A single-linked list node type and adouble-linked list node type, wherethe second type inherits from the firstone. A single-linked list node typeis a recursively defined type witha mutable attribute that repre-sents the list node linked to thegiven one. A double-linked list nodetype has an additional mutable at-tribute to represent the second link.The type system should not al-low links between different nodetypes.

Note that, in this example, thedouble-linked node type is not a sub-type of a single-linked node type;however, the type system should beflexible enough to allow code reusebetween them. The code sample usesthe keyword extends in order todescribe this relationship betweentypes. (LIST)

type T_LinkedListNode {

selftype next;

getNext():selftype

implementation { return next; };

attach(T_LinkedListNode node)


// attach1

};

type T_DoubleLinkedListNode extends

T_LinkedListNode {

selftype prev;

getPrev():selftype

implementation { return prev; };

attach(T_DoubleLinkedListNode

node) implementation ... ;

// attach2

};



T_LinkedListNode lln1, lln2;

T_DoubleLinkedListNode dlln1, dlln2;

... // Initialization of list node

// variables

lln1 := dlln1; // should cause


lln1 := lln2; // should be Ok

lln1.attach(lln2); // should call

// attach1

dlln1.attach(dlln2); // should call

// attach2

lln1.attach(dlln1); // should cause


dlln1.attach(lln1); // should cause


This test is also adopted fromBlack and Palsberg [1994]. It checkswhether the type system supportscode reuse beyond that provided bysubtyping. In other words, it checks ifcode reuse is possible between typesthat are not in a subtyping relation-ship with each other. Situations anal-ogous to the one described in this testoccur frequently when dealing withmutable types.

(8) Set union and intersection for im-mutable sets. (SET)

type T_Set(X) {

union(T_Set(Y) summand):

T_Set(lub(X,Y));

intersection(T_Set(Y) summand):

T_Set(glb(X,Y));

};

type T_Person { ... };

type T_Student subtype of

T_Person { ... };

T_Set(T_Person) sp1, sp2;

T_Set(T_Student) ss1, ss2;

... // Initialization of

// set variables

sp1 := sp1.union(sp2);

// should be Ok

sp1 := sp1.union(ss1);

// should be Ok

sp1 := ss1.union(sp1);

// should be Ok

sp1 := ss1.union(ss2);

// should be Ok

ss1 := sp1.union(sp2); // should


ss1 := sp1.union(ss1); // should


ss1 := ss1.union(sp1); // should


ss1 := ss1.union(ss2);

// should be Ok

sp1 := sp1.intersection(sp2);

// should be Ok

sp1 := sp1.intersection(ss1);

// should be Ok

sp1 := ss1.intersection(sp1);

// should be Ok

sp1 := ss1.intersection(ss2);

// should be Ok

ss1 := sp1.intersection(sp2);

// should cause compile-time error

ss1 := sp1.intersection(ss1);

// should be Ok

ss1 := ss1.intersection(sp1);

// should be Ok

ss1 := ss1.intersection(ss2);

// should be Ok

This test is designed to verify that setoperations used in SQL-like declara-tive queries can be successfully andprecisely typed. This is necessary toensure seamless integration of suchqueries into the language.

(9) Function apply. (APPLY)

apply((X):Y msg, X obj):

Y implementation ... ;

type T_Integer { ... };

type T_SmallInteger subtype of

T_Integer { ... };

type T_Person {

getAge():T_Integer;

};

type T_Child subtype of T_Person {

getAge():T_SmallInteger;

};



T_Person p := new T_Person (...);

T_Child c := new T_Child (...);

T_Integer i := 1000;

T_SmallInteger si := 5;

i := apply(getAge,p);

// should be Ok

i := apply(getAge,c);

// should be Ok

si := apply(getAge,p); // should


si := apply(getAge,c);

// should be Ok

This test is analogous to the “λ-calculus” test presented in Black andPalsberg [1994] (it differs in thatthis test also includes assignment).It is designed to verify the ability ofthe type system to deal with methodtypes and uniformly treat methods asobjects in the system.

(10) General database browser. Thebrowser should be able to deal withdatabases that have an unknownschema.5 (BROWSER)

printNumber(T_Number num)


type T_Person {

getAge():T_Integer;

};

T_Object root;

T_Database db;

db.open();

root := db.getRoot();

typecase root.typeOf() {

subtype of T_Number: {

printNumber(root); ... };

// should be Ok

subtype of T_Person: {

printNumber(root.getAge());

... };

// should be Ok

5 The given code only tests the ability of the typesystem to deal with dynamic type information in atype-safe manner. A complete browser would also re-quire the ability to examine the type structure of pre-viously unknown types.

otherwise: {

print("Something else"); };

};

root.getAge();


printNumber(root.getAge());


This test checks the ability of a typesystem to handle partial type speci-fications and dynamic type checking.Both are on the list of requirementsfor an OODBPL type system.

This set of requirements and tests willbe used in the next section to evaluate ex-isting languages and type systems.

3. TYPE SYSTEMS REVIEW

In this section, type systems of many cur-rent languages6 as well as theoretical de-velopments in the area will be reviewed.These type systems and languages arelisted in Table I. The table gives referencesand sections in this article where a givensystem is reviewed.

3.1. C++

C++ [Stroustrup 1991] is currently one ofthe most widely used object-oriented pro-gramming languages. C++ types combinethe characteristics of interface and imple-mentation types in that they define boththe interface and the structure of their ob-jects. Classes in C++ are special cases oftypes: classes specify properties of first-class objects, while types specify proper-ties of non-first-class objects. C++ inher-itance rules are novariant; however, C++allows polymorphic function and methodspecifications by using a method (func-tion) signature instead of a name for

6 Due to the enormous number of languages con-stantly being developed by the scientific community,this review has to be incomplete. However, every ef-fort has been made to include known languages withinteresting type system features (or their analogs).Thus, we hope that none of the essential type sys-tems are left out.



Table I. Type System Index

References Reviewed in SectionC++ [Stroustrup 1991] 3.1E [Richardson et al. 1993] 3.2O++ [Agrawal and Gehani 1989] 3.3O2 [Lecluse et al. 1992] 3.4Java 1.1 [Arnold and Gosling 1996], 3.5

[Drossopoulou and Eisenbach 1997], [Saraswat 1977]Generic Java (GJ) [Bracha et al. 1998c, 1998a, 1998b] 3.5Java parametric extension (JPE) [Myers et al. 1997] 3.5Pizza [Odersky and Wadler 1997; Agesen et al. 1997] 3.5Virtual types in Java (JVT) [Thorup 1997; Bruce et al. 1998] 3.5ODMG/OQL 2.0 [Cattell et al. 1997, Alagic 1997, 1999] 3.6SQL-99 [SQL 1999] 3.7XQuery 1.0 [W3C 2002] 3.8Modula-2 [Wirth 1983] 3.9DBPL [Schmidt and Matthes 1994] 3.10Modula-90 [Lutiy et al. 1994] 3.11Modula-3 [Harbison 1992] 3.12Oberon-2 [Mossenbok and Wirth 1993; Roe and Szyperski 1997] 3.13Lagoona [Franz 1997] 3.14Theta [Day et al. 1995] 3.15Ada 95 [Kempe Software Capital Enterprises 1995] 3.16Eiffel [Meyer 1988] 3.17Sather [Stoutamire and Omohundro 1996] 3.17Emerald [Raj et al. 1991] 3.18BETA [Madsen et al. 1993] 3.19VML [Klas and Turau 1992] 3.20Napier88 [Morrison et al. 1996] 3.21Smalltalk [Goldberg and Robson 1989] 3.22Strongtalk [Bracha and Griswold 1993] 3.22Cecil [Chambers 1993, 1992] 3.23BeCecil [Chambers and Leavens 1996, 1997] 3.23Mini-Cecil [Litvinov 1998] 3.23Transframe [Shang 1997] 3.24CLOS [Bobrow et al. 1988] 3.25Dylan [Apple Computer, Inc. 1994] 3.26TM [Bal et al. 1993] 3.27ML [Miller et al. 1990; Wright 1993] 3.28Machiavelli [Ohori et al. 1989; Buneman and Ohori 1996] 3.29Fibonacci [Albano et al. 1995] 3.30ML≤ [Bourdoncle and Merz 1996a, 1996b] 3.31Constrained types in ML [Aiken et al. 1994; Aiken and Wimmers 1993; 3.31

Pottier 1998; Rehof 1998]Constrained types in Erlang [Marlow and Wadler 1997] 3.31λ&-calculus [Castagna et al. 1995] 3.31PolyTOIL [Bruce et al. 1995, 1994] 3.32Loop [Eifrig et al. 1995a, 1995b, 1995c] 3.33TL [Matthes and Schmidt 1992; Matthes et al. 1994] 3.34TooL [Gawecki and Matthes 1996] 3.35TOFL [Qian and Krieg-Brueckner 1996] 3.36

identification purposes. In the presence ofstatic type checking, this is equivalent toa restricted form of static multiple dis-patch. Non-first-class objects in C++ areoperated upon by free functions; only ob-jects (instances of classes) have methods.C++ also provides parametric types (tem-plates) that can take an arbitrary num-ber of parameters; parametric types canbe subtyped.

The C++ type system is not verifiablein general due mostly to its unrestricteduse of pointer conversions; however, par-

tial verification is possible and is per-formed at compilation time. The C++type system combines interface and im-plementation inheritance and thus vio-lates the first inheritance requirement.It is not completely uniform as it distin-guishes between “data” and “objects” andtreats attributes in a special way. C++ pro-vides alimited substitutability for objectpointers (not for objects). In terms of ex-pressibility, the C++ type system is quitepowerful as it has function types, paramet-ric types, orthogonal type constructors,



and deals with mutable object types. How-ever, when used on the test suite, theC++ type system fails all tests exceptfor GENSORT. Other tests can be pro-grammed, but only with significant type-checking lapses. The reason for this is thefact that C++ does not handle the typ-ing of binary methods since it lacks mul-tiple dispatch. Parametric types in C++can only be used when fully instantiated,thus limiting a programmer’s ability todefine polymorphic functions (methods).Type parameters are always unrestrictedand novariant. The variant of C++ that in-cludes run-time type information (RTTI)allows for dynamic type checking (allow-ing it to tentatively pass the BROWSERtest). Intersection and union types cannot be represented by the C++ type sys-tem. The C++ type system is also quitecomplicated.

3.2. E

E [Richardson et al. 1993] is derived fromC++ and borrows much of the type andclass system from it. Differences betweenE and C++ lie in the specification of para-metric types and in the fact that E is a per-sistent language. In E (as opposed to C++)parametric types (called generic classes)can be specified using a general type pa-rameter restriction mechanism; however,subtyping for parametric classes can notbe defined in E. This mechanism allowsa programmer to specify restrictions onmethods of a parameter type. For exam-ple, it is possible to require a certain func-tion (method) parameter type to have acompare method with a given specifica-tion, thus making the test SORT succeed.As a persistent language, E is not com-pletely uniform as its persistence is type-dependent. E also fails the BROWSERtest.

3.3. O++

O++ [Agrawal and Gehani 1989] is an-other persistent language derived fromC++. It is similar to C++ in all respects ex-cept for provisions for persistence, queries,

and a limited form of type-reflection. Per-sistence in O++ is not type-based, thus itstype system is uniform in this respect.7Type reflection in O++ is provided bythe means of the is operator that checkswhether a given object has a given type.However, the BROWSER test in O++ stillfails with respect to type checking eventhough it can potentially be programmed.The SETS test also fails as O++ queriesdo not provide the full power of SQL eventhough the typing for forall and suchthatis present in O++ at the operator (non-user-definable) level.

3.4. O2

O2 [Lecluse et al. 1992] provides a fam-ily of languages, but its type system isthe same in all of them, so our discus-sion is based upon the CO2 language,which is based on C. The type system ofO2 makes a distinction between first-classand non-first-class objects (called values inO2; however, values in O2 are mutable). O2uses the term type to refer to implemen-tation types of non-first-class objects, andthe term class to refer to types of first-classobjects, which combine properties of inter-face and implementation types. Thus, thetype system of O2 is not completely uni-form in that only first-class objects are ma-nipulated by methods, much like in C++.Inheritance in O2 is based on implemen-tation subtyping, with an additional abil-ity to add or modify methods. O2 adopts acovariant signature refinement rule, thusproviding for more natural data modeling.However, in the absence of multiple dis-patch, this covariant rule results in theloss of static type safety, and thus the typesystem of O2 is unsound. O2 does not pro-vide any kind of parametricity; methods,messages, and types are not objects in O2.O2 is uniform in terms of persistence (itis orthogonal to the type). O2 also makesprovisions for dynamic schema evolution;however, this evolution is not type-safe.

7 O++ still does not have orthogonal persistence,as its persistence is declaration-based; also, persis-tent object creation is different from transient objectcreation.



O2’s type system essentially fails all testsfor type system expressiveness, since eventhe tests that could be programmed wouldpass type checking and fail at run-time.In Boyland and Castagna [1995], multi-methods are used to provide type safetyfor covariant specifications in the O2 pro-gramming language. With the addition ofthe mechanisms described in the article,test POINT would succeed, while the oth-ers would still fail.

3.5. Java

Java [Arnold and Gosling 1996] has re-cently become a popular language in bothacademic and industrial communities. Itstype system shares many features withthat of C++; therefore, the discussion willfocus primarily on its differences fromthe latter. The advantages of the Javatype system include separation betweeninterface and implementation, better han-dling of run-time type information, andsimplification of the overall type systemdesign resulting in a much more trans-parent type system. A nonreflexive Javafragment has been shown to be type-safe[Drossopoulou and Eisenbach 1997], whilethe full language has certain type deficien-cies [Saraswat 1997]. On the other hand,the Java type system lacks method types(all methods when considered as objectshave the same type in Java 1.1), paramet-ric types (except for statically unsafe para-metric arrays, which are built-in), and in-herits some of the problematic features ofthe C++ type system discussed above. Javafails all tests except for SORT, the latterbeing successful due to the presence of in-terfaces. Java fails the GENSORT test asits method types are not sufficiently ex-pressive for this test.

Recently, several parametric extensionsto the Java type system have been pro-posed. Generic Java (GJ) [Bracha et al.1998c, 1998a, 1998b] adds parametrictypes to the static type system, while us-ing the same run-time model (type pa-rameters are erased and do not exist atrun-time). Parametric types in GJ are no-variant and parameters can only be of ref-erence (class) types. There are also several

restrictions on the usage of parametrictypes and methods, related to the par-ticular type inferencing algorithm usedin GJ. GJ passes the test COMPARA-BLE and the union part of the SET testin addition to the SORT test passed byJava 1.1.

Another parametric type extension ofJava is proposed in Myers et al. [1997](JPE). It allows usage of nonreferencetypes as type parameters and also useswhere-clauses to express requirements onparameter types. In this extension, para-metric types are also novariant. The type-checking algorithm is not presented inMyers et al. [1997]. This extension hastest suite performance identical to that ofGeneric Java, but provides a more uniformsystem. These two approaches are infor-mal in that they do not have a theoreticalproof of their soundness.

Yet another Java extension is Pizza[Odersky and Wadler 1997], which ex-tends Java with parametric and functiontypes. The approach taken in Odersky andWadler [1997] is similar to that of Myerset al. [1997], but is much better formal-ized. In fact, Pizza would have been stat-ically type-safe if not for covariant arraysthat were left in Pizza for Java compatibil-ity. It is shown that the resulting type sys-tem does not have the subsumption prop-erty. However, the same is true of all Javaextensions considered so far as well as ofJava itself. Pizza passes tests GENSORTand APPLY in addition to COMPARABLEand SORT due to the presence of methodtypes. A similar set of extensions is pro-posed in Agesen et al. [1997], but withoutmethod types and a supporting theory. Thelatter approach, however, does lift severalrestrictions placed on the usage of type pa-rameters in Pizza.

A different approach is taken by Thorup[1997], where Java is extended with vir-tual types (JVT). Here the choice is madein favor of convenience, and both statictyping and (dynamic) substitutability aresacrificed. Because of this, tests PER-SON, COMPARABLE, and LIST couldbe programmed, but would give run-timerather than compile-time errors in incor-rect cases. A modification of this approach



is presented in Bruce et al. [1998], whichalso compares parametric and virtual typeapproaches.

Boyland and Castagna [1997] extendsJava with multi-methods that are intro-duced via so-called parasitic methods. Thegoal of this extension is to add supportfor multi-methods to the existing lan-guage providing full compatibility withJava. Boyland and Castagna [1997] con-tains a proof of soundness for the resultingsystem.

3.6. ODMG Object Model

The Object Database Management Grouphas developed a set of standards for objectdatabase management systems [Cattellet al. 1997]. Two of these standards specifyan object model (ODMG Object Model) andan object query language (OQL). The ob-ject model includes types that specify ab-stract properties and abstract behavior oftheir objects. Types are categorized as in-terfaces (abstract behavior only), classes,and literals (abstract state only). Typesare implemented by language-specific rep-resentations; a single type can have sev-eral representations, but only one of themcan be used in a single program. Inter-faces support multiple inheritance, whileclasses only support single inheritance(class extension). Thus, the ODMG Ob-ject Model provides separation betweeninterface and implementation. Interfacesin this model can not be instantiated.Abstract properties in the ODMG ObjectModel include abstract state and abstractrelationships (two-way mappings). Rela-tionships can only be defined betweenclasses. Abstract behavior is specified asa set of operations. Behavior specifica-tions are novariant in both their ar-gument and return types. The ODMGObject Model supports single dispatch.Several system-defined parametric con-tainer classes are present in the objectmodel, but the user is not allowed to de-fine new ones. Type parameters can onlybe used in property specifications; oper-ation specifications can not be parame-terized. OQL is a strongly typed querylanguage that provides a possibility of ex-

plicit dynamically checked type conver-sions. Set operations in OQL can only beperformed on “compatible types” (typesthat have the least upper bound). Sincethe notion of the greatest lower bound isnot available in OQL, all set operationsuse the least upper bound for typing pur-poses. For example, intersecting a set ofstudents with a set of persons would re-turn a result of type “set of persons” evenin the case when the type of students isa subtype of the person type. ODMG/OQLfails all tests except for BROWSER andthe union part of the SET test. It shouldbe noted, however, that ODMG/OQL isnot a general-purpose database program-ming language, and therefore its perfor-mance on the test suite is not fully in-dicative of the merits of the ODMG ObjectModel.

The ODMG object model has also beenanalyzed in Alagic [1997] from the pointof view of type checking. It has beenshown that sound and verifiable type-checking of OQL queries is impossible toachieve. In Alagic [1999], it has also beenshown that OQL queries could be verifi-ably typechecked if both the ODMG typesystem and the ODMG language bindingssupported parametric polymorphism andconstrained types. This extension to theODMG model does not change its perfor-mance on the test suite.

3.7. SQL-99

The SQL-99 language standard [SQL1999] extends the industry standarddatabase query language SQL with a sig-nificant number of new features, includ-ing computationally complete semipro-cedural language and object-orientedextensions such as user-defined data typesand dynamically dispatched methods.

The type system of SQL-99 consistsof predefined (built-in), constructed, anduser-defined types. Constructed types in-clude array types, reference types, and rowtypes. Constructed types are parameter-ized: an array type specifies the type ofits elements and maximum allowed cardi-nality, a reference type specifies its refer-enced type, and a row type specifies a set of



type-value pairs (row types are primar-ily used for table specifications). The con-structed types are special: the user is notallowed to change their behavior or definenew constructors. Data (objects) of differ-ent types do not have the same status inthe language.

In addition to types, there is also thenotion of domain. Domain is essentially adata type plus a set of predicates restrict-ing the possible values of that type. Do-main usage, however, is restricted: for ex-ample, domain can not be used to specifythe type of a procedural parameter.

User-defined types can be either struc-tured or distinct. Distinct types are dis-tinct synonyms of predefined types. User-defined subtyping can not be specified fordistinct types. Structured types have sin-gle inheritance. There is an additional re-quirement that every subtype family musthave exactly one common supertype. Itis also possible to specify that a user-defined type is abtract (noninstantiable)or final (nonsubtypable). SQL-99 has thesubsumption property.

User-defined types can define methods.For structured types, methods can be no-variantly overridden and dynamically dis-patched according to the receiver type. Itis also possible to define CONSTRUCTOR andSTATIC methods. Each data type attributeautomatically defines accessor and muta-tor methods; however, these methods cannot be overridden.

In SQL-99, the user can specify func-tions and routines that are not methods(i.e., they are not attached to any type).These routines can be overloaded; the rou-tine to execute is determined statically, ac-cording to the type specificity of all theparameters. It is required that such de-termination be unambiguous. Routine pa-rameters can be specified as input, out-put, or input-output. A limited form of typeparametricity is allowed: a function (ora method) can be type-preserving. In thiscase, one of the input parameters can bespecified as a RETURN parameter that willgive its type to the result of function appli-cation. However, the validity of this asser-tion is not statically guaranteed. There-fore, a run-time type check is performed

when the value is returned to ensure thatits run-time type is the same as (or a sub-type of ) the run-time type of the specifiedparameter.

A mechanism is provided for user-defined sorting and comparison that al-lows the user to define comparison proce-dures for all user-defined types. However,this mechanism is special, and can notbe applied to binary methods other thancomparison.

SQL-99 routines, types, methods, andfunctions can be persistent, either as partsof a schema or as parts of a persistentmodule.

SQL-99 has an extensive declarativequery mechanism based on a significantlyextended version of the standard SQLSELECT statement. The query mechanismis integrated with array indexing, refer-ence processing, and path expressions thatallow direct access to object attributesand methods. Procedural capabilities, in-cluding assignment, are also supported;however, there is no concept of instance-update methods. In other words, apply-ing a “mutator” method always “creates”a new instance that must in turn be as-signed to the old instance. All system-generated mutator methods are thereforetype-preserving.

SQL-99 is statically and strongly typed.It is also fully reflexive, allowing full dy-namic schema modification and manipu-lation. Run-time type inspection is alsosupported.

Overall, the SQL-99 type system is ver-ifiable and fully reflexive, while beingnon-uniform and lacking most of the ad-vanced expressibility features. As a re-sult, it fails all the tests except for theBROWSER test and the union part of theSET test. The SORT test can also be pro-grammed, but only using the special mech-anism designed specifically for sorting andcomparison.

However, just as in the case of theODMG object model, it should be notedthat the main focus of SQL-99 is not ageneral-purpose object-oriented databaseprogramming language, and therefore itsperformance on the test suite is not fullyindicative of the merits of the SQL-99



standard. For example, useful notionssuch as triggers, access rights, transactionatomicity, while being extremely impor-tant, are beyond the scope of this surveysince they do not affect the type system.

3.8. XQuery

XQuery 1.0 [W3C 2002] is a query lan-guage for retrieving and interpreting in-formation stored in XML format. AnXQuery program is a set of XQuery func-tions; there is no notion of method dis-patch, since data are considered to be pas-sive elements of processing. In XQuery,data types are regular grammars. Forexample, data of the type denoted as((A|B)∗, C+, A∗) consist of a sequence ofone or more data items of type A or B,followed by one or more data items oftype C, followed by zero or more dataitems of type A. Since XQuery is a purelyfunctional language, it does not need typ-ing rules for assignment or mutable data.XQuery has subsumption, and its (struc-tural) subtyping is based on grammar in-clusion (type t1 is a subtype of t2 if andonly if the language generated by t1 gram-mar is a subset of the language gener-ated by t2). XQuery supports static type-checking. The XQuery type system alsosupports statically typed typecase state-ment that allows type-safe queries overdata with a structure that is not known atcompile time. On the other hand, there iscurrently no support for overloaded func-tions, user-defined higher-order functions,or user-defined parametric types. Thus,this type system lacks most of advancedexpressibility features.

At the time of writing, XQuery isstill being developed, and many of itstype system features have not been fi-nalized. For example, it has not beendecided whether user-defined subtypingwill be added; whether user-defined poly-morphic functions will be allowed; howmetadata queries should be constructedand typed; or whether static typecheckingwill be mandatory or merely suggestive.Many theoretical aspects of the proposedtype system also need further develop-ment, such as semantics and handling

of intersection types (interleaved types inXQuery). This makes it impossible to re-liably apply the tests to the XQuery typesystem at this time.

3.9. Modula-2

The following group of languages is based,directly or indirectly, on Modula-2 [Wirth1983]. Modula-2 is neither an object-oriented nor a persistent language. Itstype checking is verifiable. Modula-2 hasa construct for separating interface andimplementation in the form of interfaceand implementation modules, and the lan-guages based on Modula-2 also use thisapproach. This mechanism has provento be very convenient and robust forprocedural languages. However, its ad-vantages and disadvantages for object-oriented languages with their primarilytype-based approach to both interface andimplementation specification are yet to beevaluated.

3.10. DBPL

DBPL [Schmidt and Matthes 1994] isone of the persistent languages basedon Modula-2. In DBPL, modularity isachieved by using the native language(Modula-2) modularization mechanismswith a special DATABASE MODULE construct.In the absence of module persistence, itdoes not cause problems with orthogonal-ity. Transactions are supported as specialprocedures. Partial SQL compatibility isprovided by the use of a RELATION OF typeconstructor with the appropriate set ofoperations and first-order constructs ALLIN, SOME IN, and FOR EACH. DBPL also al-lows updatable and nonupdatable views(via SELECTOR and CONSTRUCTOR procedu-ral specifications). DBPL is not object-oriented; however, it does offer implemen-tation types (with no methods). The DBPLtype system is static and nonreflexive.The tests described in Section 4 are notapplicable to DBPL directly as it is notobject-oriented. DBPL would tentativelypass only the test GENSORT. The DBPLtype system is uniform in that system anduser-defined types have the same rights.



3.11. Modula-90

Another persistent language based onModula-2 is Modula-90 [Lutiy et al. 1994].Modula-90 has some rudimentary object-oriented capabilities (single inheritance)and is similar to C++ in that method sig-natures are novariant, object types are dif-ferent from other types, implementationand interface hierarchies coincide, andthere is only a limited support for func-tion types. Thus, the Modula-90 type sys-tem is not uniform. An interesting prop-erty of Modula-90 is the presence of typeDYNAMIC. Data of this type are pairs ofvalues and their types expressed as val-ues of a compound type DATATYPE. TypeDATATYPE is the type of the representa-tions of all data types in the system; itcan be used independently of the DYNAMICtype to store, retrieve, and operate uponvarious data types. Any value can be co-erced to the type DYNAMIC. Modula-90 pro-vides a special operator TYPECASE thatprovides a type-safe interface to the val-ues of type DYNAMIC. The language alsoprovides a set of predefined type opera-tors that can be used to operate on valuesof type DATATYPE. Thus, Modula-90 pro-vides type-safe immutable type reflection.The Modula-90 type system is static andnon-parametric; however, it does provideorthogonal persistence. The only express-ibility tests that succeed in Modula-90 areGENSORT and BROWSER. Modula-90provides incremental type checking, in-cluding its dynamic variety.

3.12. Modula-3

Modula-3 [Harbison 1992] is anotherlanguage with object-oriented extensionsbased on Modula-2. Modula-3 is not apersistent programming language and itsobject extensions are similar to those ofModula-90; it also has TYPECASE state-ment that gives a programmer the abil-ity to request dynamic type checking ina type-safe manner. Modula-3 has param-eterized modules; however, parameterizedtypes are not allowed. Modula-3 passes thetests COMPARABLE, SORT, GENSORT,and BROWSER.

3.13. Oberon-2

Another descendant of Modula-2 isOberon-2 [Mossenbok and Wirth 1993].Subtyping in Oberon-2 is based on recordextension, also known as structuralsubtyping. The subtyping relation-ship is predefined for atomic types.Thus, Oberon-2 has multiple subtyping.Oberon-2 supports single dispatch. Sub-typing of procedure (method) types isbased on novariance of argument andresult types; only the receiver type is co-variant. Parametricity is not supported byOberon-2. Separation between interfaceand implementation is supported at thelevel of modules in the same manner as inall Modula-2 based languages. Oberon-2also has an extended WITH statementthat allows a programmer to dynamicallyinspect the type of an object and actaccording to it. This statement is similarto the TYPECASE statement in Modula-3and Modula-90 discussed earlier. Thetype system of Oberon-2 would pass thetests SORT, GENSORT, and BROWSER.

There has been a proposal for addingparametric types and methods to Oberon[Roe and Szyperski 1997]. In this pro-posal, parametric types are novariant, andthe type checker ensures that a param-eter type substitution exists that satis-fies the rules for matching argumentsof a particular call. Unfortunately, nei-ther the typechecking algorithm nor theproof of its soundness are present inRoe and Szyperski [1997].

3.14. Lagoona

Lagoona [Franz 1997] is another descen-dant of Oberon. It focuses on messages,objects, and message passing. In contrastto most object-oriented languages, a mes-sage in Lagoona is an independent en-tity. An interface (category in Lagoona)is a set of messages. Each message hasa type specification. There can be sev-eral methods implementing a message,each for a different receiver type. Imple-mentation in Lagoona is specified by aclass (usually a record type); when a cate-gory meets a class, a type (combination of



interface and implementation) is born. Nocode inheritance is possible in Lagoona,only structure inheritance is possible.Variables in Lagoona can be specifiedusing either category or class. Lagoonathus provides a complete separation be-tween interface, implementation (repre-sentation), and code (methods). When amessage is sent to an object, an objectcan forward (resend) it to another object.Other features of the Lagoona type systeminclude single dispatch and single inher-itance. Unfortunately, the article [Franz1997] provides insufficient information totest the performance of Lagoona on thetest suite.

3.15. Theta

The language Theta [Day et al. 1995] com-bines the expressive power of parametricand inclusion polymorphisms. It also pro-vides where-clauses that give its type sys-tem a flexibility similar to that providedby matching. Theta has single dispatch,multiple inheritance for types (interfaces),and single inheritance for classes (imple-mentations). Theta only allows novariantparametric types. Method types can bespecified in Theta and methods (functions)can be used as first-class values. Thetaalso has reflexive capabilities in the formof the typecase operator. Theta’s type sys-tem is verifiable, uniform, and static. It isalso quite expressive. However, its sound-ness has not been proven. Theta passes thetests COMPARABLE, SORT, GENSORT,LIST, and BROWSER.

3.16. Ada 95

The language Ada 95 [Kempe SoftwareCapital Enterprises 1995] is a procedurallanguage with some object-oriented fea-tures. Ada 95 has a remarkably strongsupport for parametricity: generic pack-ages (parametric modules) and genericsubprograms (parametric functions) cannot only be instantiated, but also used asparameters of other generic entities, thusproviding for great flexibility. Parametertypes can be constrained by a with clauserequiring the type to have a method with a

particular signature, which can also be pa-rameterized. However, Ada generics haveto be fully and explicitly instantiated be-fore they can be used. Another interestingand powerful feature of Ada is the notion ofan access type which generalizes such no-tions as “pointer” and “reference”, allow-ing also for user-defined access types. Adaalso has function types, and function argu-ments can be specified as in, out, or inoutaccording to the role they play. Ada uses itspackage mechanism (similar to the modulemechanism of Modula-2) to provide sep-aration between interface and implemen-tation. On the other hand, object-orientedAda 95 features appear to be relativelyweak: in order to be used for dynamicdispatch, a type has to be explicitly de-clared as tagged. In order to be able touse subtyping (inclusion) polymorphism,a programmer has to use a special form ofparameter specification. Ada provides sin-gle dispatch and single inheritance withnovariant methods. Subclassing in Ada islimited to record extension. In Ada, typescan be examined dynamically; data of atype can be converted to any other type,and such a conversion is dynamically type-checked. The Ada type system is very com-plicated and it places emphasis on staticrather than dynamic polymorphism. Adawill pass the tests COMPARABLE, SORT,GENSORT, LIST, and BROWSER, pro-vided generic packages rather than typesare used.

3.17. Sather

Next, the object-oriented language Sather[Stoutamire and Omohundro 1996] will beconsidered. Sather is based on the muchbetter known Eiffel [Meyer 1988]; how-ever, Eiffel is not discussed here as oneof the primary goals behind the designof Sather was to remedy typing problemspresent in Eiffel.

Sather has multiple interface andimplementation inheritance hierarchiesalmost independent of each other (con-crete implementation types called classesin Sather must have leaf interface types).Implementation subtyping in Sathercorresponds to textual inclusion with



replacements. Sather uses single dispatchand is strongly and statically typed.Therefore, its methods are covariant onthe receiver and contravariant on otherarguments. Sather also provides partialclosures of its methods and iterators asfirst-class values. It has parametric im-plementation types that can use a form ofbounded polymorphism to constrain typeparameters. These parametric types arenovariant and they can not be used untilfully instantiated. Method argumentsin Sather can be specified as in, out, orinout, according to the role they play. TheSather type system correctly handles allthese cases. Argument types and localvariables can be specified by using eitherSather types or Sather classes. In theformer case, the parameter class has to bea subtype of the given type; in the lattercase, the parameter class has to match thespecification exactly. The language alsoprovides a novel notion of iters (iterators)that are an object-oriented generalizationof loop control structures. Sather alsoprovides a special compound type TYPEand operators typeof and typecase. Thus,it has type-safe immutable type reflec-tion. The type system of Sather thereforepossesses verifiability (even though it hasnot been formally proven) and satisfiesinheritance and (partially) uniformityand expressibility requirements. It passestests PERSON, COMPARABLE, SORT,GENSORT, LIST, and BROWSER andfails on tests POINT, STREAMS, SET,and APPLY. Note that APPLY fails be-cause parametric types in Sather requirefull instantiation before they can be used.

3.18. Emerald

Emerald [Raj et al. 1991] is a nontra-ditional object-oriented language thatcombines features of class-based anddelegation-based object-oriented lan-guages. Objects are created in Emeraldby a special syntactic form called anobject constructor. The object constructorplays a triple role: first, it defines theobject’s implementation; second, it de-fines a publicly visible object interface(type in Emerald); third, it denotes the

process of object creation itself. Subtypingin Emerald is structural, as a type isunderstood as a set of signatures. Typesare also objects that can be created byobject constructors; thus, a user candefine new types, including parametricones. The type checker uses user-definedtypes along with system-supplied onesto typecheck a program statically. Sincetypes are objects, dynamic type checkingis also possible. The Emerald type systemis therefore verifiable, uniform, reflexive,satisfies inheritance requirements, andis quite expressive. However, its sound-ness is unknown. Emerald passes thetests PERSON, STREAMS, SORT, andBROWSER.

3.19. BETA

BETA [Madsen et al. 1993] is a uniqueobject-oriented language that unifies thenotions of class, object, and procedure(method) via its notion of a pattern.Patterns can contain other patterns(such as member objects, code fragments,and types). BETA also has fragments thatplay the role of modules and can also beused to separate interface from implemen-tation. BETA fragments can be regardedas high-level restricted patterns since theyoperate on the same basic principles. Pat-terns can be virtual; a virtual patterncan be extended by adding code fragmentsin places specified by the inner place-holder (also known as method extensionas in Simula-67 [Birtwistle et al. 1979]),by extending a virtual pattern with ad-ditional members (also known as recordextension), or by supplying a class pat-tern in place of a virtual one (also knownas parametric instantiation). Virtual pat-terns have to be explicitly declared assuch. Unification of all language conceptsusing the notion of pattern makes it pos-sible to design a very powerful languagebased on only a couple of orthogonal prin-ciples. While the language design simplic-ity is very impressive, the resulting lan-guage is quite unconventional. Structuralsubtyping in conjunction with a class sub-stitution mechanism makes the type sys-tem of BETA statically unsound; dynamic



type checks are inserted to ensure typesafety. Due to the uniformity of BETA, alltests except for POINT can be coded init, but only SORT and GENSORT havestatic type safety. Illegal usage in othertests would cause run-time type errors.

3.20. VML

In the persistent object-oriented languageVML [Klas and Turau 1992], all objectsthat are instances of object types (calledclasses) are persistent while all (non-first-class) objects of nonobject types (calleddata types) are transient. However, a valueof a non-object type can become persistentif it is referenced from a persistent object.Thus, VML does not have orthogonal per-sistence. VML object types are first-classobjects and as such belong to their respec-tive metaclasses. Metaclasses define someof the essential class methods, for examplethe methods for the inheritanceBehaviormessage that is used when a method for amessage is not found in the receiver class.Thus, VML allows user-defined method in-heritance due to its “classes are objects”concept. However, VML data types are notfirst-class objects and thus VML only par-tially satisfies the type reflexivity require-ment. Inheritance in VML can be tailoredto specific application needs by using theuser-definable inheritanceBehavior mes-sage found in an appropriate metaclass.VML does not have a verifiable type sys-tem, therefore the tests are not applicableto it.

3.21. Napier88

The persistent programming languageNapier88 (version 2) [Morrison et al. 1996]is not an object-oriented programminglanguage; however, its type system isquite powerful. In Napier88, parametrictypes can be built freely from the basictypes, type constructors, and type vari-ables. Parametric procedures (procedureswith parametric types) can also be de-fined and are first-class objects. Napier88types are purely implementation types;however, Napier88 provides the type con-structor abstract that may be considered

as an interface type as it provides exis-tential quantification over witness type(s).Thus, the type system of Napier88 satis-fies all expressibility requirements not re-lated to the notions of subtyping and in-heritance. However, since Napier88 doesnot have the notions of subtyping and in-heritance, it fails the requirements relatedto those notions. In Napier88, paramet-ric types can not be used until fully in-stantiated. Napier88 provides support fora limited form of linguistic reflection viadynamic environments. Environments aredynamically typed structures that providebindings of names to Napier88 entities.Environments can be dynamically modi-fied, inspected and used in expressions.Environments can be persistent.

Napier88 has a special type any that is aunion type of all types in the system. A spe-cial project operator can be used to dealwith values of type any in a type-safe man-ner. This operator is similar to TYPECASEof Modula-90. Since any value can be in-jected into type any, the above mechanismmakes run-time data type inspection pos-sible. Thus, the type system of Napier88has type-safe type reflexive capabilities.

The persistent store of Napier88 is anobject of type any that holds a typed col-lection of objects. The objects from the per-sistent store can be projected from anyand operated upon transparently afterthat. Napier88 uses a persistence modelbased on reachability from the root (per-sistent store) object. Thus, the persistencein Napier88 is orthogonal to type.

In spite of the power of its type system,Napier88 only unconditionally passesthe test LIST. However, it tentativelypasses the tests COMPARABLE, SORT,GENSORT, and APPLY if usage of explicittype parameters in parametric calls is al-lowed. In other words, the burden of infer-ring correct parametric instantiation fromthe code in Napier88 is placed on a pro-grammer rather than on the type checker.

3.22. Strongtalk

Strongtalk [Bracha and Griswold 1993]is a statically typed version of Smalltalk[Goldberg and Robson 1989]. Smalltalk



is widely regarded as the first purelyobject-oriented language; however, it hasno static type checking.

In Strongtalk, everything (includingtypes, called classes in Strongtalk, meth-ods, and messages) is a first-class ob-ject. Thus, Strongtalk is uniform.8 AllStrongtalk objects can be operated uponand modified at run-time and thereforeStrongtalk is reflexive (the reflexivity istype-unsafe). Strongtalk separates inter-faces (protocols) from implementations(classes), provides subtyping and match-ing. It also has parametric (novariant)types and messages, block types, andunion types. However, the user has to ex-plicitly specify a mechanism to guide para-metric type inferencing, resulting in theloss of substitutability. It is also unclearfrom Bracha and Griswold [1993] whetherStrongtalk allows bounded parametrictypes. Strongtalk provides single inheri-tance and single dispatch. Subtyping isstructural, but the user can use brandsto restrict it. Even though Strongtalk wasnot designed to be a persistent language,it does provide uniform persistence of itsobjects in a so-called image. Overall, theStrongtalk type system is quite expres-sive, uniform, and reflective. It passes thetests COMPARABLE, LIST, BROWSER,and, possibly, GENSORT (if parametrictype bounds are allowed). The union partof the SET test is also passed. Strongtalkwould fail the tests PERSON, POINT,STREAMS, as well as APPLY and SORT(the latter two could be programmed, butonly with blocks rather than messages).

3.23. Cecil

Cecil [Chambers 1993, 1992] is adelegation-based language that has bothimplementation and interface types (theformer are called representations whilethe latter are called types). Types in Cecilare used for suggestive type-checkingonly as Cecil’s multiple dispatch is doneaccording to representations. Cecil’stype checking is suggestive because it

8 Except for a possible uniformity breach in the formof direct attribute access.

might report false errors or miss realones, therefore its type discipline is notenforceable. Cecil’s does not supportincremental type checking. Cecil usesmultiple dispatch and provides covariantspecification of specialized argumentstogether with contravariant specifica-tion of unspecialized ones. Closures andmethods are first-class objects in Cecil;they are contravariantly typed. Cecilalso provides novariant parametric typesand methods as well as type parameterbounds. Parametric types in Cecil can beinstantiated either explicitly or implicitly;in the latter case, the user has to providea hint to the type inferencing algorithm.This behavior results in loss of substi-tutability. Cecil has multiple inheritance,union and intersection types. Overall, theCecil type system is quite expressive anduniform, while being nonreflexive9 andstatic. It also satisfies the inheritancerequirements. Since Cecil type checkingis only suggestive, it is difficult to applythe tests to it. However, tests that Cecilwould tentatively pass include PERSON,POINT, SORT, GENSORT, LIST, SET,APPLY, and BROWSER. It would failthe tests COMPARABLE (due to therestrictions on parametric type bounds)and STREAMS (due to the novariance ofparametric types).

There are several extensions/modifica-tions to the original Cecil language. Oneof these extensions is BeCecil [Chambersand Leavens 1996, 1997]. BeCecil is a stat-ically typechecked version of Cecil. It sup-ports block and modular structure, hasextensible objects and an extensible typesystem, and its type system has been for-malized. However, soundness and substi-tutability properties have yet to be proven.BeCecil also has a novel notion of accep-tors which can be considered as an object-oriented generalization of the assignmentoperator. However, BeCecil does not have

9 Being a delegation-based language, Cecil has lan-guage reflection; however, the type system of Cecil isnot reflexive as Cecil types are not objects and cannot be manipulated by the language. More precisely,representations of Cecil are reflexive while types arenot.



parametric types while sharing most ofthe other features with Cecil. The absenceof parametricity contributes to the de-creased expressibility of the BeCecil typesystem as compared to that of Cecil. Be-Cecil passes the tests PERSON, POINT,SORT, GENSORT, and LIST, and failsthe rest.

Another modification (Mini-Cecil) is de-scribed in Litvinov [1998]. Mini-Cecilstrives to achieve a combination of statictyping and a very general form of para-metric polymorphism. Mini-Cecil also hasframeworks which are basically interfaceswith what appears to be an analog ofselftype. The frameworks can be usedto separate interface and implementation,as well as to achieve the effect of match-ing. Methods in Mini-Cecil are first-classobjects; multi-methods and multiple in-heritance are supported. Subtype clausescan have a form of forall α C1 isa C2:C3 isa C4, where α is a set of free typevariables and Ci are type specifications.The resulting type system is very expres-sive; it can even be argued that it isthe most expressive type system possi-ble. However, the typechecking seems tobe undecidable. The algorithm proposedis a conservative approximation, and itssoundness is yet to be proven. It is alsounknown if the resulting type system hassubstitutability. Mini-Cecil would pass alltests except for BROWSER as it does nothave reflexive capabilities.

3.24. Transframe

Transframe [Shang 1997] allows the userto specify whether a parameter of a para-metric type is to be covariant or novariant(type-exact) and to constrain it by givingit an upper bound. Subtyping and sub-classing (interface and implementation in-heritance) are different concepts in Trans-frame. There is a distinct name selfclassthat allows classes to support matching.The language unifies the notions of classand function (like BETA). Transframe alsosupports multiple dispatch. There are pro-visions for dynamic type checking anddynamic schema evolution. Transframeimplicitly instantiates parameter types in

expressions; unfortunately, there is no for-mal proof of type safety. In fact, it can beshown that the type system presented inShang [1997] is not type-safe. Overall, theTransframe type system is verifiable, veryexpressive, almost uniform, and dynam-ically reflective. However, it is unsound.Transframe would pass all expressibilitytests except for the test STREAMS (due toits inability to represent contravarianttype parameters) and the intersection partof the test SET (due to the absence of in-tersection types).

3.25. CLOS

CLOS (Common LISP Object System)[Bobrow et al. 1988] is a reflexive lan-guage, with all the power of CommonLISP reflection. CLOS has types and ob-ject types (called classes), the latter be-ing a subset of the former. CLOS typesare implementation types; they do notspecify any interface. However, CLOSclasses combine implementation and in-terface definitions. Since CLOS makes adistinction between object and non-objecttypes (where only object types define in-terfaces and are subject to inheritance),the CLOS type system is not completelyuniform. CLOS classes are objects that be-long to metaclasses, which are also objects;CLOS messages, methods, and functionsare also CLOS objects that can be operatedupon and changed at run-time, so CLOSis fully reflexive and dynamic. Subclass-ing in CLOS is slot collection extensionwith slot types changed covariantly (a typeof a slot is the intersection of the typesspecified for this slot in all of the class’superclasses). Messages (called genericfunctions) are also covariant. CLOS is notstatically typed. A CLOS message can bedispatched to yield an appropriate method(or a combination of methods) according tothe class or value of all arguments (mul-tiple dispatch). Methods are covariant onall arguments10 since CLOS has multi-ple dispatch. If more than one method isappropriate for the given arguments, a

10 More precisely, methods are covariant on those ar-guments that are constrained by class specifications.



user-definable way of constructing thefunction to be executed out of all ap-propriate methods is employed. In thebody of a method, a special functioncall-next-method can be called to invokethe next applicable method. This capabil-ity is analogous to the inner constructof Simula-67 [Birtwistle et al. 1979] andis much more powerful. Overall, the dis-patch mechanism of CLOS is the mostpowerful of all known mechanisms, if theconsideration is limited to classes andvalues. CLOS can not dispatch on types.Updates in CLOS are invoked on slotsdirectly or by using an appropriate mes-sage. CLOS is not statically type checked,therefore a run-time error is signalled ifa value assigned to a slot does not con-form to the slot’s type specification. SinceCLOS is not statically typed, the tests arein general, not applicable to it; however,CLOS would pass POINT, APPLY, andBROWSER tests if its type discipline wereenforceable.

3.26. Dylan

Dylan [Apple Computer, Inc. 1994] is animperative programming language simi-lar to CLOS. While there are certain dif-ferences between the two, they are almostidentical in terms of their type systems.Dylan has more control over the definedclasses, as Dylan classes can be sealed(only subclassable by the library wherethey belong) or open, primary (there isonly single inheritance of primary classes)or free, abstract (all superclasses of anabstract class must be abstract) or con-crete. There is also support for singletontypes, but not singleton classes. Multipledispatch in Dylan is also different fromthat in CLOS in that in Dylan all argu-ments are equal, and the method speci-ficity is defined by a class precedence list.Dylan also has modules with import andexport lists and module libraries.

3.27. TM

TM [Bal et al. 1993] is an object-orientedpersistent language with many functionalfeatures. TM has a verifiable type sys-

tem based on Cardelli [1988]. However,the soundness proof seems to be miss-ing. TM’s type hierarchy includes user-definable sorts (atomic, immutable types)and classes. Sorts and classes have rep-resentation (implementation) types thatare almost hidden inside of them. Methodsand types are not first-class values in TM.TM method specification uses selftypeto achieve the effect of matching. Sincethis is the only polymorphic mechanismin TM, specifications are covariant andsubstitutability does not hold, as func-tional updates are present. No methodredefinition mechanisms are provided inTM. The TM type system extends the typesystem of Cardelli [1988] with a power-set type constructor. Since TM is stateless,powerset types are covariant. TM allowsenumerated as well as predicative setsas primitive language expressions. Enu-merated sets in TM can only be homoge-neous, while predicative sets can be het-erogeneous up to subtyping. Predicativesets in the presence of the record-basedtype system of Cardelli [1988] and the ab-sence of updates play a role of embeddedqueries that are highly integrated with therest of the language. TM provides severallevels of constraint specification mecha-nisms which are also set-based and resem-ble relational constraint systems. TM alsoprovides first-order set operations. How-ever, the set operations require specialtreatment and are not messages in theusual object-oriented sense. It is also un-clear how well different type constraintsfor different kinds of sets interact witheach other. TM has modules that definetheir persistent components by names,and everything those objects refer to isalso implicitly persistent. Thus, TM pro-vides a combination of static name-basedand dynamic reachability-based persis-tence, completely orthogonal to the type.Overall, the TM type system is verifi-able, sound, supports both interface andimplementation inheritance (though theyare not completely independent of eachother), is almost uniform, partially expres-sive, and provides support for declarativequeries. However, it does not support sub-stitutability and is nonreflexive and static.



It would unconditionally pass tests SORTand LIST. Test SET also succeeds be-cause of built-in support for set operations.However, it would not be possible to con-struct user-defined types with the samefunctionality.

Most of the following languages bor-row much of their expressiveness fromML [Miller et al. 1990]. ML is a languagewith both functional and imperative fla-vors; it also has some object-oriented fea-tures. This can be said about almost all thelanguages discussed below.

3.28. ML

Standard ML [Miller et al. 1990] is afunctional language with some impera-tive features. It is strongly typed andprovides provably decidable and soundtype checking. In the ML type system,all type information is inferred by thetype checker. Addition of explicit typeannotations and declarations is consid-ered in Odersky and Laufer [1996].Standard ML also provides a very so-phisticated module system, where eachmodule (structure) has its type (signa-ture). However, ML’s structures are morelike abstract (implementation) types thanmodules, as they are designed to shieldtheir internals from the rest of the pro-gram and not to handle separate compi-lation or similar tasks. There is no no-tion of subtyping in Standard ML, exceptfor signature matching, which can be con-sidered as restricted structural subtyp-ing for abstract (interface) types. Highlyparametric types are supported in Stan-dard ML. They can arbitrarily includetype variables and can be user-defined.Thus, the type system of Standard ML isuniform. For interface types (signatures)there are also functions that map signa-tures to signatures (functors). Functiontypes in ML can also be polymorphic.Polymorphism in Standard ML functiontypes is expressed via type expressionsthat have to be “pattern-matched”. For ex-ample, the type of the identity functionin Standard ML is ‘a → ‘a, where ‘ais a type variable. This kind of polymor-phism is uniform in that it allows user-

defined parametric types. Standard ML,being in essence functional, allows up-dates on so-called ref types. These typesare reference types somewhat similar topointer types in C or C++. ref types havea restricted parametricity, as an argumentof a ref type must always be a mono-type (e.g., see discussion in Wright [1993]).Types are not objects in Standard MLeven though they can be operated uponby functions similar to those that oper-ate on ordinary values. Overall, the typesystem of Standard ML is theoreticallysound, very expressive and uniform, whilelacking inheritance and being only par-tially reflexive. This type system wouldtentatively11 pass tests PERSON, SORT,GENSORT, and APPLY (for the testSORT use of modules rather than typesis required).

3.29. Machiavelli

Another language from this family isMachiavelli [Ohori et al. 1989; Bunemanand Ohori 1996] which is a persistent lan-guage that extends ML by adding morepolymorphism as well as query and viewsupport. Machiavelli has a verifiable andprovably sound type system. It adds recordinclusion polymorphism to ML by usingtype variables of the form (a’’), that cor-respond to an arbitrary record extension.Thus Machiavelli allows “more polymor-phic” types than ML. Machiavelli is alsoable to automatically maintain more so-phisticated (even noncovariant) type con-straints on description types.12 It is there-fore possible for Machiavelli’s type checkerto statically infer an error in case a joinof two sets of records whose types do nothave a greatest lower bound is attempted.Machiavelli’s type system treats descrip-tion and other types differently. Thus, itis not completely uniform. In Machiavelli,a special set type constructor {} is intro-duced and query operations are defined forobjects of set types. Machiavelli extends

11 Provided that the notion of subtyping is substi-tuted by the notion of code reuse.12 Description types are ML types that do not include→ outside of ref.



the type system of ML to be able to dealconsistently with type inference of gener-alized relational operations. Machiavellialso provides views similar to those in re-lational databases. Namely, a Machiavelliview is defined as a function that returnsa projection of a given set over some ap-propriate type. Machiavelli views are notupdatable. Overall, the type system ofMachiavelli is verifiable, sound, very ex-pressive, reflexive, partially uniform, par-tially dynamic, and capable of supportingviews. However, it lacks interface inheri-tance. It passes the same tests as ML withthe addition of the SET test due to the spe-cial support of sets by the language andthe type system.

3.30. Fibonacci

Fibonacci [Albano et al. 1995] is a per-sistent object-oriented language that isa descendant of Galileo [Albano et al.1985], which is, in turn, based on ML.It has some functional and imperativefeatures and possesses a verifiable, prov-ably sound type system; it also has mul-tiple inheritance and single dispatch. InFibonacci, object types are independentfrom each other in terms of subtyping;however, role types form independent di-rected acyclic graph (DAG) subhierar-chies for each object type. For exam-ple, an object of type PersonObject canplay roles Person, Employee, Student, andTeachingAssistant (who is both Employeeand Student). Fibonacci roles can bedynamically created and Fibonacci ob-jects can dynamically acquire new roles.Fibonacci types are not objects in the lan-guage. Method arguments in Fibonacci arecontravariant, while their results are co-variant. Fibonacci supports a distinctionbetween methods and functions: meth-ods are attached to role types and arenot Fibonacci objects, while functions areindependent and are first-class values.Fibonacci also has nonobject and nonroletypes, such as basic types, class types,function types, and association types.These types form a hierarchy independentof that of object and role types. Fibonaccidefines some built-in parametric types

(Class, Sequence, and Association). How-ever, it is unclear from Albano et al. [1995]if the user can create new parametrictypes. In Fibonacci, objects of the sameobject type can have different implemen-tations. These implementations are de-fined at the time of object creation. Thus,an implementation in Fibonacci is not apart of an object or role type specifica-tion. Updates in Fibonacci are allowed onspecial novariant Var types. In Fibonacci,the syntax of message sends determinesthe strategy of the method lookup. Thereare two strategies: upward lookup, thatcorresponds to the standard lookup pro-cedure in the presence of multiple inheri-tance, and double lookup, that first tries tofind an appropriate method in the subrolesof the role it has started from. Fibonacci of-fers declarative query operators on para-metric Sequence types. These are typesof immutable sequences that are super-types of their respective mutable Classand Association types. Thus, the queryfacilities of Fibonacci are also applica-ble to Fibonacci classes and associations.Fibonacci has a reachability-based orthog-onal persistence model. Everything acces-sible from the top-level environment auto-matically persists between sessions. Thus,Fibonacci persistence is orthogonal to bothinterface and implementation types. Over-all, the Fibonacci type system is verifiable,provably sound, provides different inher-itance for interface and implementationtypes, and has inclusion polymorphism(substitutability). It is also expressive, al-most uniform, and is capable of supportingquery typing. However, it is non-reflexiveand static. The type system of Fibonacciwould pass the same tests as that ofMachiavelli.

3.31. ML≤ and Other Subtyping Mechanismsfor ML

The language ML≤ [Bourdoncle and Merz1996a, 1996b] is an extension of MLwith subtyping and higher-order poly-morphic multi-methods. It has type in-ference, strong static type checking, andsubstitutability. ML-like type constructorsprovide parametric polymorphism. Type



constructors in ML≤ can be specified as co-variant, novariant, or contravariant. Theformalism used is based on systems of typeconstraints. In this theoretical language,no separation between interface and im-plementation is provided. Handling of im-perative (mutable) types is borrowed fromML and is quite restrictive with respect topolymorphism. Another restriction placedon ML≤’s type system is the requirementthat all types that have a subtyping re-lationship should have the same numberof arguments as well as the same vari-ance specification for them. Thus, this typesystem fails the test STREAMS as it re-quires a subtyping relationship to be es-tablished between parametric types of dif-ferent variances. Overall, the ML≤ typesystem is expressive, verifiable, sound,and static. It passes the tests PERSON,POINT, SORT, GENSORT, APPLY, andthe union part of the SET test. However,the inability of the system presented inBourdoncle and Merz [1996a] to deal withrecursive constraints makes generaliza-tion of the system to unrestricted subtyp-ing of parametric types quite difficult.

There are several other approaches toadding subtyping to ML, but none ofthem deals with multi-methods. Aikenand Wimmers [Aiken et al. 1994; Aikenand Wimmers 1993] proposed a systemthat finds a solution for a system ofsubtyping constraints; this system candeal with recursive constraints. Pottier[1998] also proposed a system in whichrecursive constraints are allowed; insteadof solving the constraints, his systemproves their consistency (like that of ML≤).Sequeira [1998] also adds subtyping anduser-defined type constructors, as well asconstrained types, to an ML-style type sys-tem. The resulting system appears to besimilar to that of ML≤, but lacks its abilityto deal with multi-methods. Complexityresults related to solving subtyping sys-tems appear in Rehof [1998].

Marlow and Wadler [1997] proposes atype system for a core subset of the purelyfunctional language Erlang [Armstronget al. 1996]. The type system is simi-lar to the one proposed by Aiken andWimmers [Aiken et al. 1994; Aiken and

Wimmers 1993] and uses constrained typeentailment for type verification. The maindifference is the absence of function types,general unions, and intersections. The sys-tem is provably sound and presumablycomplete. Addition of function types tothe system makes it incomplete, and theproof of soundness in this case is absent.Marlow and Wadler [1997] includes de-cidable algorithms for type inferenc-ing, signature verification, and constraintsimplification.

Castagna et al. [1995] proposed an ex-tension of λ-calculus (λ&-calculus) dealingspecifically with multi-methods. Severalimportant results (generalized subject re-duction, Church-Rosser etc.) are proven.It is also shown how the calculus can beused to model inheritance, matching, andmultiple dispatch.

Chen and Odersky [1994] presented atype system where a full-fledged supportfor mutable types is added to an ML-style type system. The approach taken bythe authors separates mutable and im-mutable types by creating a parallel lan-guage syntax. In essence, every functionallanguage construct has its imperativecounterpart. Interaction between mutable(imperative) and immutable (functional)language components is restricted by a setof type validity rules that restrict polymor-phism of data types for the data passed be-tween the two language components. Theapproach of Chen and Odersky [1994] ap-pears to be sound, but soundness seemsto be achieved at the expense of languagesimplicity and type system transparency.

3.32. PolyTOIL

PolyTOIL [Bruce et al. 1995, 1994] hasa verifiable and sound type system andsingle subtyping. PolyTOIL identifies sub-typing with substitutability, while pro-viding a concept of matching (subtypingup to MyType). The latter is introducedto allow for covariant method specifica-tion. Subtyping in PolyTOIL is structural,as is matching. The language allows forboth subtyping and matching constraints.Matching is used as a mechanism of spec-ifying constraints that are weaker than



substitutability and is therefore useful forupdatable types. In Bruce [1996], it is sug-gested that subtyping should be droppedaltogether as matching is more intuitiveand more flexible. In Bruce et al. [1995],there are distinct notions of object typesand class types. The former are interfacetypes, while the latter are implementationtypes. Namely, object types specify signa-tures (type information) for methods ap-plicable to the objects of this object type,while class types specify instance vari-ables and code for methods applicable toobjects that belong to the class. Classesare used to create new objects. They areproduced by applying functions whose ar-guments are values used to initialize theproduced objects as well as the argumenttypes for parametric classes to their argu-ments. Classes can use inheritance withredefinitions. Parametric types in Poly-TOIL are pattern functions of their pa-rameter types. A notion of a function typeis also present in PolyTOIL. However, itis only used in specifications and duringtype-checking and is inherently differentfrom either class or object type. Overall,the type system of PolyTOIL is verifiable,sound, expressive, almost uniform, andsatisfies inheritance requirements. How-ever, it is static and nonreflexive. It passestests COMPARABLE, SORT, GENSORT,LIST, and APPLY and fails the rest. ThePERSON test fails, because while recordsubtyping allows method type redefini-tion, record extension does not.

3.33. Loop

Loop [Eifrig et al. 1995c, 1995b, 1995a] is atheoretical language similar to PolyTOIL.There are no explicit type annotationsin Loop and the typing is inferred auto-matically. Loop has a concept of subclass-ing where one class inherits from severalother classes. Subtyping and subclassingin Loop are different concepts. Loop en-joys provably sound type-checking and astate semantics given by its translation toSoop. Function types are present in Loop;however, in the absence of explicit type an-notations, they are only used internallyfor type checking purposes. Loop classes

are mechanisms for creating objects. Sub-classes do not necessarily correspond tosubtypes and class and type inheritancehierarchies are different. The type hier-archy in Loop is implicit, while the classhierarchy is explicitly specified by the pro-grammer. Subclassing can be multiple andboth methods and instance variables canbe added, inherited, or modified. SinceLoop is a “theoretical” language, it doesnot have any syntactic sugar for subclass-ing which makes Loop inheritance ratherdifficult to use. Updates in Loop are al-lowed for instance variables only. The se-mantics of these updates is given by theirtranslation to Soop. Loop does not haveparametric types. Subtyping in a simi-lar system has been shown to be decid-able in Trifonov and Smith [1996]. Thetype system of Loop is verifiable, sound,partially expressive, almost uniform, par-tially reflexive, static, and satisfies theinheritance requirements. It passes thesame tests as PolyTOIL. The type check-ing mechanism uses constrained types.The system does not attempt to find asolution to the system of constraints itgenerates; rather, it verifies that such asystem is noncontradictory. The theoryguarantees that in this case the systemhas a solution and the program is consid-ered to be type-correct.

3.34. TL

TL (Tycoon Language) [Matthes andSchmidt 1992; Matthes et al. 1994] isbased on the F<: system [Cardelli et al.1991; Cardelli 1993]. From F<:, it borrowsconstrained (bounded) parametric typesand type operators, as well as polymor-phic functions and partial type inference.It is also uniform in its treatment of func-tions (including higher-order ones) andatomic values. In addition to these fea-tures, TL has mutable types, modules,and a typecase statement. Even thoughTL is designed on the basis of a for-mal system (F<:), its type system featureshave not been mathematically proven.Thus, the questions of soundness and de-cidability remain open for the TL typesystem. TL is an orthogonally persistent



programming language. Since TL is not anobject-oriented language, the tests are notapplicable to it.

3.35. TooL

In the TooL language [Gawecki andMatthes 1996], an attempt is made tocombine the notions of subtyping, match-ing, and bounded universal quantification.The resulting language is quite powerfulin terms of supporting different kinds ofrelationships between types. However, ithas significant complexity and requiresgood anticipation by type specifiers to cor-rectly choose the kind of type relation-ship that is needed before any subclassesof the class in question are created. Thetheoretical aspects of the language do notseem to be fully developed, as neithersoundness nor decidability of type check-ing has been proven. TooL supports singledispatch. Interface and implementationsubtyping (termed respectively as subtyp-ing and subclassing) are different in TooL.Parametric types can be specified, and thetype parameters can be bounded. Informa-tion presented in Gawecki and Matthes[1996] is insufficient to judge the unifor-mity and reflexivity of the type system;however, it seems to be static and very ex-pressive. Gawecki and Matthes [1996] alsostates that TooL is a persistent language;however, nothing else is said about its per-sistence. The performance of this type sys-tem with respect to the test suite is identi-cal to that of the type systems of PolyTOILand Loop.

3.36. TOFL

The language TOFL [Qian and Krieg-Brueckner 1996] is a theoretical object-oriented functional language. It hasmultiple dispatch, novariant argument re-definition, function types, and paramet-ric types. TOFL allows subtype specifica-tions of the form “if x is a subtype of Eq,then list(x) is a subtype of Eq for any typex”. All parametric types in TOFL are co-variant, except for functionals which arenovariant in their first argument (func-tion argument position). This is justified

since TOFL is a functional (stateless) lan-guage. TOFL has a verifiable and provablysound type system. The TOFL type sys-tem is also quite expressive as it passesthe tests PERSON, POINT, SORT, GEN-SORT, APPLY, and the union part of thetest SET.

4. CONCLUSIONS

The comparison between the type systemsis presented in Tables II, III, and IV. Notall of the languages and systems listedin Table I are present in these tables;those that are superseded by other typesystems reviewed in this paper, languagesthat have no static type systems, and in-complete type systems are excluded fromthe review tables.

Table II lists features of the reviewedtype systems that correspond to the re-quirements listed in Section 2.6. Veri-fiability is understood as the presenceof a decidable type checking algorithm.Static soundness means that a success-fully typechecked program does not pro-duce errors at run-time, while dynamicsoundness means that the program re-ports all possible type errors at run-timein a well-defined and predictable man-ner. Static soundness is strictly strongerthen dynamic soundness. The columnuniformity/atomics means that objects ofprimitive (atomic) types have the samerights as objects of user-defined types.The column uniformity/methods refers tothe ability of a language to treat meth-ods (or messages, or both) as objects.Reflection/typecase indicates the ability ofa language to deal with dynamic typechecking in a type-safe manner. Finally,reflection/evolution shows whether a givenlanguage supports incremental type sys-tem evolution.

Table III compares various aspects oftype system expressibility. The first twocolumns indicate whether a given typesystem has a notion of subtyping, showswhat kind of subtyping (structural (im-plicit) or user-defined (explicit)) it sup-ports, and what kind of inheritance (sin-gle or multiple) the type system has. Thethird column shows whether the type



Table II. Type System Features

Soundness Separation between interfaceType system Verifiability Static Dynamic and implementationC++ + – – –E + – – –O++ + – – –O2 + Unknown Unknown –Java 1.1 + – Core only +GJ + – Unknown +JPE + – Unknown +Pizza + +1 + +JVT + – Unknown +ODMG 2.0 + Unknown Unknown +SQL-99 + Unknown Unknown –DBPL + Unknown Unknown +2

Modula-90 + Unknown Unknown +2

Modula-3 + Unknown Unknown +2

Oberon-2 + Unknown Unknown +2

Theta + Unknown Unknown +Ada 95 + Unknown Unknown +2

Sather + + + +Emerald + Unknown Unknown +BETA + – Unknown +2

Napier88 + + + +/–Strongtalk + Unknown Unknown +Cecil + – Unknown +BeCecil + Unknown Unknown +Mini-Cecil Unknown Unknown Unknown +Transframe + – Unknown +TM + Unknown n/a –ML + + n/a +2

Machiavelli + + n/a –Fibonacci + + n/a +/–ML≤ + + n/a –PolyTOIL + + n/a –Loop + + n/a +TL + Unknown Unknown –TooL Unknown Unknown n/a +TOFL + + n/a –

Uniformity ReflectionType system Substitutability Atomics Methods Typecase EvolutionC++ +3 – + – –E +3 – + – –O++ +3 – + –/+5 –O2 – – – – +/–7

Java 1.1 +/– – – + –GJ – – – + –JPE – – – + –Pizza – + + + –JVT – – – + –ODMG 2.0 – – – + –SQL-99 +4 – – + +DBPL n/a n/a + – –Modula-90 +4 – + + –Modula-3 + – + + –Oberon-2 + – + + –Theta Unknown – + + –Ada 95 – – + + –Sather + – + + –Emerald + + – + +/–7

BETA + + + + +/–7

Napier88 n/a n/a + + +Strongtalk – + + + +/–7

Cecil – + + +/–6 +BeCecil Unknown + + – +Mini-Cecil Unknown + + – –Transframe Unknown + + + +TM – + – – –ML n/a + + – –Machiavelli + + + – –Fibonacci + + + – –ML≤ + + + – –PolyTOIL + + + – –Loop + + + – –TL Unknown + + + –TooL Unknown + + – –TOFL + + + – –

1 Except for covariant arrays which have been kept in Pizza only for backward compatibility with Java. 2 These features are based on mod-ules(packages, fragments) rather than on types. 3 Substitutability works for pointers and references only. 4 For object types only. 5 Eventhough a type can be examined dynamically in O++, typechecking does not take this into account. 6 Classes (implementation types) only.7 Evolution is type-unsafe.



Table III. Type System Expressibility

SubtypingType system Inheritance Method types DispatchC++ User-defined Multiple + Single5

E User-defined Multiple + Single5

O++ User-defined Multiple + Single5

O2 User-defined ? – SingleJava 1.1 User-defined Multiple3 – SingleGJ User-defined Multiple3 – SingleJPE User-defined Multiple3 – SinglePizza User-defined Multiple3 + SingleJVT User-defined Multiple3 – SingleODMG 2.0 User-defined Multiple3 – SingleSQL-99 User-defined Single – SingleDBPL User-defined n/a + n/aModula-90 User-defined Single + SingleModula-3 User-defined Single + SingleOberon-2 Structural n/a + SingleTheta User-defined Multiple3 + SingleAda 95 User-defined Single + Single6

Sather User-defined Multiple + SingleEmerald Structural n/a – SingleBETA Structural Single + SingleNapier88 – n/a + n/aStrongtalk Structural1 Single +4 SingleCecil User-defined Multiple + MultipleBeCecil User-defined Multiple + MultipleMini-Cecil User-defined Multiple + MultipleTransframe User-defined Multiple + MultipleTM Both Multiple – SingleML Structural n/a + n/aMachiavelli Structural n/a + n/aFibonacci User-defined2 Single Unknown n/aML≤ Both Multiple + MultiplePolyTOIL Structural n/a + Single7

Loop Structural n/a + Single7

TL Structural n/a + n/aTooL Structural Multiple + Single7

TOFL User-defined2 Multiple3 + MultipleParametric types Mutable Intersection

Type system Bounded Intra Inter types typesC++ + – – + + –E + + – + + –O++ – n/a n/a n/a + –O2 – n/a n/a n/a + –Java 1.1 – n/a n/a n/a + –GJ + + – + + –JPE + + – + + –Pizza + + – + + –JVT + + –/+11 + + –ODMG 2.0 –/+8 n/a –/+11 – + –SQL-99 –/+13 – –/+11 – + –DBPL – n/a n/a n/a + –Modula-90 – n/a n/a n/a + –Modula-3 +9 – n/a n/a + –Oberon-2 – n/a n/a n/a + –Theta + – – + + –Ada 95 + + – + + –Sather + + – + + –Emerald + – n/a n/a + UnknownBETA + + n/a n/a + –Napier88 + – n/a n/a + –Strongtalk + ? – + + –Cecil + + – + + +BeCecil – n/a n/a n/a + +Mini-Cecil + + + + + +Transframe + + +/–12 + + –TM + – –/+11 + – –ML + – n/a + +/– –Machiavelli – n/a n/a n/a +/– +Fibonacci + – n/a n/a +/– ImplicitML≤ + – + +/– +/– ImplicitPolyTOIL + + n/a n/a + –Loop – n/a n/a n/a + ImplicitTL + + –/+11 + + –TooL + + – + + –TOFL + ++10 –/+11 + – Implicit

1 Structural subtyping is the default; however, user can explicitly turn it off when needed. 2 User-defined for classes; structural for algebraicdata types. 3 Only for interfaces; classes have single inheritance. 4 Block types only. 5 Only virtual functions are dispatched. 6 Only tagged typesare dispatched. 7 Dispatch modeled as record field extension/execution. 8 Only system-defined; parameters can only be used for specification ofproperties. 9 These features are based on modules rather than on types. 10 The language provides mechanism more expressive then boundedquantification. 11 Always covariant. 12 Only covariant and novariant parameters are allowed. 13 Only system-defined: ARRAY and REF.



Table IV. Type System Tests

Type system PERSON POINT COMPARABLE STREAMS SORTC++ – – – – –E – – – – +O++ – – – – –O2 – – – – –Java 1.1 – – – – +GJ – – + – +JPE – – + – +Pizza – – + – +JVT –/+1 – –/+1 –/+1 +ODMG 2.0 – – – – –SQL-99 – – – – –/+9

DBPL – – – – –Modula-90 – – – – –Modula-3 – – + – +Oberon-2 – – – – +Theta – – + – +Ada 95 – – + – +Sather + – + – +Emerald + – – + +BETA –/+1 – –/+1 –/+1 +Napier88 – – +/–4 – +/–4

Strongtalk – – + – –/+5

Cecil +/–2 +/–2 – – +/–2

BeCecil + + – – +Mini-Cecil + + + + +Transframe + + + – +TM – – – – +ML + – – – +Machiavelli + – – – +Fibonacci + – – – +ML≤ + + – – +PolyTOIL –/+3 – + – +Loop –/+3 – + – +TooL –/+3 – + – +TOFL + + –/+1 – +Type system GENSORT LIST SET APPLY BROWSERC++ + – – – +/–7

E + – – – –O++ + – –6 – –/+8

O2 – – – – ??Java 1.1 – – – – +GJ – – union – +JPE – – union – +Pizza + – union + +JVT – –/+1 –/+1 – +ODMG 2.0 – – union6 – +SQL-99 – – union – +DBPL + – – – –Modula-90 + – – – +Modula-3 + – – – +Oberon-2 + – – – +Theta + + – – +Ada 95 + + – + +Sather + + – – +Emerald – – – – +BETA + –/+1 –/+1 –/+1 –/+1

Napier88 +/–4 + – +/–4 +Strongtalk + + union –/+5 +Cecil +/–2 +/–2 +/–2 +/–2 +/–2

BeCecil + + – – –Mini-Cecil + + + + –Transframe + + union + +TM – + –6 – –ML + – – + –Machiavelli + – +/–6 + –Fibonacci + – +/–6 + –ML≤ + – union + –PolyTOIL + + – + –Loop + + – + –TooL + + – + –TOFL + – union + –

1 Relies on dynamic type checking. 2 Only suggestive type-checking. 3 While the subtyping relationship required by the test holds, one typecan not be derived from the other. 4 If type parameters are explicitly instantiated. 5 This test can be only programmed with blocks rather thanmessages. 6 Built-in operators for dealing with sets are provided; however, their typing is special (non-user-definable). 7 If RTTI is present.8 Even though a type can be examined dynamically, typechecking does not take this into account. 9 Only using a special support for sortingand comparison in SQL-99.



system supports method (function) types.The fourth column addresses the issueof dispatch (single or multiple) in thegiven type system. Columns 5 through 8deal with parametricity and its relation-ship with subtyping. Column 5 indicateswhether a given type system supportsparametric types. Column 6 shows if atype system can deal with constrainedparametric types. Positive indication incolumn 7 means that a type system makesit possible for different parametric typesformed using the same type constructor tohave a subtyping relationship with eachother (for example, T Set(T Person) is asubtype of T Set(T Student). Column 8 in-dicates whether the type system is capa-ble of specifying subtyping relationshipsbetween parametric types with differenttype constructors (e.g. T List(T Person)is a subtype of T Set(T Person)). Col-umn 9 is an indication of the ability of atype system to deal with mutable types.This indication is negative for type sys-tems of purely functional languages. Col-umn 10 shows whether a type system sup-ports intersection (greatest lower bound)types.

Finally, Table IV demonstrates the per-formance of the reviewed type systems onthe test suite.

From the analysis of the results pre-sented in Table IV it can be concludedthat languages Mini-Cecil and Trans-frame rate the best on the test suite. How-ever, none of them has provably soundtypechecking; in fact, typechecking Mini-Cecil programs is likely to be undecid-able [Litvinov 1998]. Of the systems withsound and verifiable type checking, themost impressive is Sather; however, itstype system lacks multiple dispatch andunion types. Soundness of the Sather typesystem has not been formally proven. Al-most all “theoretical” type systems showsimilar performance on the test suite.

Sound type checking, substitutability,parametricity, method types, and multi-methods appear together in only one typesystem: that of ML≤. However, ML≤ (aswell as most ML clones) severely restrictsusage of mutable types and does notdeal well with certain aspects of binary

methods and parametricity (failed testsCOMPARABLE and STREAMS).

The test STREAMS proved to be themost difficult one. This is surprising asthe test outlines the situation that occursin almost every language dealing with I/Ooperations at a relatively high level. Onlythe type systems of Emerald and Mini-Cecil were able to pass this test; however,none of these type systems has a proof ofsoundness.

Overall, type systems with nice theoret-ical properties show only moderate per-formance on the test suite, while typesystems that perform well on tests lack atheoretical basis.

It can, therefore, be concluded thatnone of the languages reviewed completelysatisfies the requirements laid down inSection 4. None of the provably sound typesystems has passed the majority of thetests. However, every test was passed byat least one type system thus showing thatthe necessary mechanisms have alreadybeen developed. It is their consistent andtheoretically sound combination that re-mains elusive so far.

A type system that satisfies the re-quirements has been developed [Leontiev1999]. This type system was not reviewedin the paper since it was developed specifi-cally to conform to the requirements listedin Section 2. However, it demonstratesthat these requirements are consistent inthat they can be satisfied together in asingle theoretically sound type system. Itis our belief that this type system will bean important first step towards the devel-opment of theoretically sound, reflexive,uniform, and dynamic persistent object-oriented programming language.

REFERENCES

AGESEN, O., FREUND, S. N., AND MITCHELL, J. C. 1997.Adding type parametrization to the Java lan-guage. In Proceedings of the OOPSLA’97.

AGRAWAL, R. AND GEHANI, N. H. 1989. ODE (ob-ject database and environment): The languageand the data model. In Proceedings of theACM-SIGMOD 1989 International Conferenceon Management of Data. 36–45.

AIKEN, A. AND WIMMERS, E. L. 1993. Type inclusionconstraints and type inference. Tech. Rep. RJ9454 (83075). IBM Research Division. August.



AIKEN, A., WIMMERS, E. L., AND LAKSHMAN, T. K.1994. Soft typing with conditional types. InConference Record of POPL ’94, 21st ACMSIGPLAN-SIGACT Symposium on Principlesof Programming Languages. ACM Press, 163–173.

ALAGIC, S. 1997. The ODMG object model: Does itmake sense? SIGPLAN Not. 32, 10, 253–270.

ALAGIC, S. 1999. Type-checking OQL queries inthe ODMG type systems. ACM Trans. Datab.Syst. 24, 3 (Sept.), 319–360.

ALBANO, A., CARDELLI, L., AND ORSINI, R. 1985.Galileo: A strongly-typed, interactive conceptuallanguage. ACM Trans. Datab. Syst. 10, 2 (June),230–260.

ALBANO, A., GHELLI, G., AND ORSINI, R. 1995. Fi-bonacci: A programming language for objectdatabases. VLDB J. 4, 403–444.

APPLE COMPUTER, INC. 1994. Dylan Interim Refer-ence Manual. Apple Computer, Inc.

ARMSTRONG, J., VIRDING, R., WIKSTROM, C., AND

WILLIAMS, M. 1996. Concurrent Programmingin Erlang, 2nd ed. Prentice Hall.

ARNOLD, K. AND GOSLING, J. 1996. The Java Lan-guage Specification, 4th ed. Addison-Wesley.

ATKINSON, M., BANCHILON, F., DEWITT, D., DITTRICH,K., MAIER, D., AND ZDONIK, S. 1992. Theobject-oriented database system manifesto. InBuilding an Object-Oriented Database System:The Story of O2, F. Banchilon, C. Delobel, and P.Kanellakis, Eds.

ATKINSON, M. AND MORRISON, R. 1995. Orthogonallypersistent object systems. VLDB J. 4, 3, 319–401.

ATKINSON, M. P. AND BUNEMAN, O. P. 1987. Typesand persistence in database programming lan-guages. ACM Comput. Surv. 19, 2 (June), 105–190.

BAL, R., BALSTERS, H., DE BY, R. A., BOSSCHAART, A.,FLOKSTRA, J., KEULEN, M. V., SKOWRONEK, J.,AND TERMORSHUIZEN, B. 1993. The TM Man-ual. Faculty of Computer Science, Universityof Twente. Version 2.0 revision C. Availableelectronically. URL: ftp://ftp.cs.utwente.nl/pub/doc/TM.

BAUMGARTNER, G., LAUFER, K., AND RUSSO, V. F. 1996.Interaction of object-oriented design patternsand programming languages. Tech. Rep. CSD-TR-96-020, Deptartment of Computer Sciences,Purdue University.

BIRTWISTLE, G. M., DAHL, O.-J., MYHRHAUG, B., AND NY-GAARD, K. 1979. Simula Begin. Studentlitter-atur (Lund, Sweden), Bratt Institute Fuer NeuesLerned (Goch, FRG), Chartwell-Bratt Ltd (Kent,England).

BLACK, A. AND PALSBERG, J. 1994. Foundationsof object-oriented languages. ACM SIGPLANNot. 29, 3, 3–11. Workshop Report.

BOBROW, D. G., DEMICHIEL, L. G., GABRIEL, R. P.,KEENE, S. E., KICZALES, G., AND MOON, D. A. 1988.Common LISP Object System specification. X3J13Document 88-002R.

BOURDONCLE, F. AND MERZ, S. 1996a. Primitivesubtyping ∨ implicit polymorphism ` object-orientation. In Foundations of Object-OrientedLanguages 3. Extended abstract.

BOURDONCLE, F. AND MERZ, S. 1996b. Type check-ing higher-order polymorphic multi-methods.In Proceedings of the 24th ACM Confer-ence on Principles of Programming Languages(POPL’24).

BOYLAND, J. AND CASTAGNA, G. 1995. Type-safe com-pilation of covariant specialization: A practicalcase. Tech. Rep. UCB/CSD-95-890, University ofCalifornia, Computer Science Division (EECS),Berkeley, Calif. Nov.

BOYLAND, J. AND CASTAGNA, G. 1997. Parasiticmethods: An implementation of multi-methodsin Java. SIGPLAN Not. 32, 10, 66–76. (Pro-ceedings of OOPSLA’97). URL: ftp://ftp.ens.fr/pub/dmi/users/castagna/oopsla97.ps.gz.

BRACHA, G. AND GRISWOLD, D. 1993. Strongtalk:Typechecking Smalltalk in a production envi-ronment. In Proceedings of the ACM Conferenceon Object-Oriented Programming: Systems, Lan-guages, and Applications.

BRACHA, G., ODERSKY, M., STOUTAMIRE, D., AND

WADLER, P. 1998a. GJ: Extending theJava programming language with type pa-rameters. Manuscript. Revised August 1998.URL: http://www.cis.unisa.edu.au/∼pizza/gi/Documents/.

BRACHA, G., ODERSKY, M., STOUTAMIRE, D., AND WADLER,P. 1998b. GJ specification. ManuscriptURL: http://www.cis.unisa.edu.au/∼pizza/gi/documents/.

BRACHA, G., ODERSKY, M., STOUTAMIRE, D., AND WADLER,P. 1998c. Making the future safe for the past:Adding genericity to the Java programming lan-guage. In Proceedings of the 13th Annual ACMSIGPLAN Conference on Object-Oriented Pro-gramming Systems, Languages, and Applica-tions (OOPSLA’98). 183–200.

BRUCE, K., CARDELLI, L., CASTAGNA, G., THE

HOPKINS OBJECT GROUP, LEAVENS, G., AND

PIERCE, B. 1996a. On binary methods. TheoryPrac. Obj. Syst. 1, 3, 221–242.

BRUCE, K. B., FIECH, A., AND PETERSEN, L. 1996b.Subtyping is not a good “match” for object-oriented languages. In Informal Proceedings ofthe 4th Workshop on Foundations of Object-Oriented Languages (FOOL 4). Contributed talk.

BRUCE, K. B., ODERSKY, M., AND WADLER, P. 1998. Astatically safe alternative to virtual types. InProceedings of the 1998 European Conference onObject-Oriented Programming (ECOOP’98).

BRUCE, K. B., SCHUETT, A., AND GENT, R. V. 1994.A type-safe polymorphic object-oriented lan-guage. Accessible by anonymous FTP. URL:ftp://cs.williams.edu/pub/kim/PolyTOIL.dvi.

BRUCE, K. B., SCHUETT, A., AND GENT, R. V. 1995.PolyTOIL: A type-safe polymorphic object-oriented language. In Proceedings of the9th European Conference on Object-Oriented



Programming (ECOOP’95), (A◦arhus, Denmark).

W. Olthoff, Ed. Lecture Notes in Computer Sci-ence, vol. 952. Springer-Verlag, New York. Ex-tended abstract.

BRUCE, K. K. 1996. Typing in object-orientedlanguages: Achieving expressibility andsafety. URL: ftp://cs.williams.edu/pub/Kim/Static.ps.

BUNEMAN, P. AND OHORI, A. 1996. Polymorphismand type inference in database programming.ACM Trans. Datab. Syst. 21, 1 (March), 30–76.

BUNEMAN, P. AND PIERCE, B. 1999. Union types forsemistructured data. Tech. Rep. MS-CIS-99-09,Department of CIS, University of Pennsylvania.

CARDELLI, L. 1986. A polymorphic λ-calculus withType:Type. Tech. Rep. 10, DEC SRC, 130Lytton Avenue, Palo Alto, CA 94301. May. SRCResearch Report.

CARDELLI, L. 1988. A semantics of multiple inher-itance. Inf. Comput. 76, 138–164.

CARDELLI, L. 1989. Typeful programming. InFormal Description of Programming Concepts,E. J. Neuhold and M. Paul, Eds. IFIP Stateof the Art Reports Series. Springer-Verlag,New York. URL: http://www.luca.demon.co.uk/Bibliography.html.

CARDELLI, L. 1993. An implementation of F<:.Tech. Rep. 97, DEC Systems Research Center.February.

CARDELLI, L. 1997. Type systems. In The Com-puter Science and Engineering Handbook, A. B.Tucker, Ed. CRC Press, Chapter 103. URL:http://www.luca.demon.co.uk/Bibliography.html.

CARDELLI, L., MARTINI, S., MITCHELL, J. C., AND SCEDROV,A. 1991. An extension of system F with sub-typing. In Proceedings of the International Con-ference on Theoretical Aspects of Computer Soft-ware, T. Ito and A. R. Meyer, Eds. Lecture Notesin Computer Science, vol. 526. Springer-Verlag,New York, pp. 756–770.

CASTAGNA, G. 1996. Object-Oriented Program-ming: A Unified Foundation. In Progress in The-oretical Computer Science. Birkauzer, Boston,Chapter Type Systems for Object-OrientedProgramming.

CASTAGNA, G., GHELLI, G., AND LONGO, G. 1995. Acalculus for overloaded functions with subtyp-ing. Inf. Comput. 117, 1 (Feb.), 115–135.

CATTELL, R. G. G., BARRY, D., BARTELS, D., BERLER, M.,EASTMAN, J., GAMERMAN, S., JORDAN, D., SPRINGER,A., STRICKLAND, H., AND WADE, D. 1997. TheObject Database Standard: ODMG 2.0. Morgan-Kaufmann, Los Altos, Calif.

CHAMBERS, C. 1992. Object-oriented multi-methods in Cecil. In ECOOP ’92, EuropeanConference on Object-Oriented Programming,(Utrecht, The Netherlands), O. L. Madsen,Ed. Lecture Notes in Computer Science, vol.615. Springer-Verlag, New York, pp. 33–56.

CHAMBERS, C. 1993. The Cecil language: Speci-fication and rationale. Tech. Rep. TR 93-03-05. Department of Computer Science and En-gineering, FR-35, University of Washington.Mar.

CHAMBERS, C. AND LEAVENS, G. T. 1996. BeCecil, Acore object-oriented language with block struc-ture and multimethods: Semantics and typing.Tech. Rep. 96-17. Department of Computer Sci-ence, Iowa State University. Dec.

CHAMBERS, C. AND LEAVENS, G. T. 1997. BeCecil, Acore object-oriented language with block struc-ture and multimethods: Semantics and typing.In FOOL 4. In Proceedings of the 4th Inter-national Workshop on Foundations of Object-Oriented Languages (Paris, France).

CHEN, K. AND ODERSKY, M. 1994. A type system fora lambda calculus with assignment. In Proceed-ings of the Theoretical Aspects of Computer Sci-ence (Sendai, Japan). Lecture Notes in ComputerScience. Springer-Verlag, New York.

CONNOR, R. C. H., MCNALLY, D. J., AND MORRISON, R.1991. Subtyping and assignment in databaseprogramming languages. In Proceedings of the3rd International Workshop on Database Pro-gramming Languages (Napfilon, Greece).

DAY, M., GRUBER, R., LISKOV, B., AND MYERS, A. C.1995. Subtypes vs where clauses: Constrain-ing parametric polymorphism. SIGPLAN No-tices 30, 10 (Oct.), 156–168.

DROSSOPOULOU, S. AND EISENBACH, S. 1997. Java istype safe—probably. In Proceedings of the 11thEuropean Conference on Object Oriented Pro-gramming (ECOOP’97).

EIFRIG, J., SMITH, S., AND TRIFONOV, V. 1995a. Soundpolymorphic type inference for objects. SIG-PLAN Notices 30, 10 (Oct.), 169–184.

EIFRIG, J., SMITH, S., AND TRIFONOV, V. 1995b.Type inference for recursively constrainedtypes and its application to OOP. ElectronicNotes in Theoretical Computer Science 1.URL: http://www.elsevier.nl/locate/entcs/volume1.html.

EIFRIG, J., SMITH, S., TRIFONOV, V., AND ZWARICO, A.1995c. An interpretation of typed OOP in a lan-guage with state. LISP Symb. Comput. 8, 4, 357–397.

FISHER, K. AND MITCHELL, J. C. 1996. The devel-opment of type systems for object-oriented lan-guages. Theory Pract. Obj. Syst. 1, 3, 189–220.URL: ftp://theory.stanford.edu/pub/jcm/papers/tapos.ps.

FRANZ, M. 1997. The programming languageLagoona—A fresh look at object-orientation.Softw—Concepts and Tools 18, 14–26.

GAWECKI, A. AND MATTHES, F. 1996. Integratingsubtyping, matching and type quantification: Apractical perspective. In Proceedings of the 10thEuropean Conference on Object-Oriented Pro-gramming (Linz, Austria). Springer-Verlag, NewYork.



GOLDBERG, A. AND ROBSON, D. 1989. ST-80, TheLanguage. Addison-Wesley, Reading, Mass.

HARBISON, S. P. 1992. Modula-3. Prentice-Hall,Eglewood Cliffs, N.J.

HAUCK, F. J. 1993. Towards the implementation ofa uniform object model. In Parallel ComputerArchitectures: Theory, Hardware, Software, andApplications—SFB Colloquium SFB 182 andSFB 342, A. Bode and M. D. Cin, Eds. LectureNotes in Computer Science, vol. 732. Springer-Verlag, New York, pp. 180–189.

KEMPE SOFTWARE CAPITAL ENTERPRISES 1995. Ada95 Reference Manual. Kempe Software Capi-tal Enterprises. Available electronically. URL:http://www.adahome.com/rm95.

KIM, W. 1993. Object-oriented database systems:Promises, reality, and future. In Proceedings ofthe 19th VLDB Conference. 676–687.

KIRBY, G. N. C., CONNOR, R. C. H., MORRISON, R.,AND STEMPLE, D. 1996. Using reflection tosupport type-safe evolution in persistent sys-tems. Tech. Rep. CS/96/10. University of St.Andrews.

KLAS, W. AND TURAU, V. 1992. Persistence inthe object-oriented database programming lan-guage VML. Tech. Rep. TR-92-045, InternationalComputer Science Institute, 1947 Center St.,Suite 600, Berkeley, CA 94704-1198. July.

LALONDE, W. R. AND PUGH, J. 1991. Subclassing 6=subtyping 6= is-a. J. Obj. Orient. Prog. 3, 5 (Jan.),57–62.

LEAVENS, G. T. AND MILLSTEIN, T. D. 1998. Multipledispatch as dispatch on tuples. In Proceedingsof the Conference on Object-Oriented Program-ming, Systems, Languages, and Applications(OOPSLA’98). ACM, New York, pp. 374–387.URL: http://www.cs.washington.edu/homes/todd/papers/oopsla98.ps.

LECLUSE, C., RICHARD, P., AND VELEZ, F. 1992. O2,an object-oriented data model. In Building anObject-Oriented Database System: The Story ofO2, F. Banchilon, C. Delobel, and P. Kanellakis,Eds.

LEONTIEV, Y. 1999. Type system for an object-oriented database programming language.Ph.D. dissertation. Department of ComputingScience, University of Alberta. Also available asTech. Rep. TR 99-02.

LEONTIEV, Y., OZSU, M. T., AND SZAFRON, D. 1998. Onseparation between interface, implementation,and representation in object DBMSs. In Proceed-ings of TOOLS–26’98. Santa Barbara, Calif.

LITVINOV, V. 1998. Constraint-based polymor-phism in Cecil: Towards a practical and statictype system. In Proceedings of the 1998 Confer-ence on Object-Oriented Programming: Systems,Languages, and Applications (OOPSLA’98).

LUTIY, V. G., MERKOV, A. B., LEONTIEV, Y. V., GAWRILOW,E. J., IVANOVA, N. A., IOFINOVA, M. E., PAKLIN, M. L.,AND HODATAEV, A. K. 1994. DBMS Modula–90K. RAN Data Processing Center, Moscow

(In Russian: Sistema Programmirovaniya BazDannyh Modula-90K).

MADSEN, O. L., MøLLER-PEDERSEN, B., AND NYGAARD,K. 1993. Object-Oriented Programming inthe BETA Programming Language. Addison-Wesley, Reading, Mass.

MARLOW, S. AND WADLER, P. 1997. A practical sub-typing system for Erlang. In Proceedings of theSecond International Conference on FunctionalProgramming (Amsterdam, The Netherlands).

MATTHES, F., MUSSIG, S., AND SCHMIDT, J. W. 1994.Persistent polymorphic programming in Tycoon:An introduction. FIDE Technical Report SeriesFIDE/94/106. Department of Computing Sci-ences, University of Glasgow, Glasgow G128QQ.August.

MATTHES, F. AND SCHMIDT, J. 1991. Bulk types:Built-in or add-on? In Proceedings of the 3rdInternational Workshop on Database Program-ming Languages. Morgan-Kaufmann, Los Atlos,Calif.

MATTHES, F. AND SCHMIDT, J. 1992. Definition of theTycoon languages—A preliminary report. Tech.Rep. FBI-HH-B-160/92, Universitat Hamburg.October.

MEYER, B. 1988. Eiffel—The language. Prentice-Hall.

MILLER, R., TOFTE, M., AND HARPER, R. 1990. TheDefinition of Standard ML. MIT Press.

MORRISON, R., BROWN, F., CONNOR, R., CUTTS, Q.,DEARLE, A., KIRBY, G., AND MUNRO, D. 1996.Napier88 Reference Manual. University of St.Andrews. Release 2.2.1.

MOSSENBOK, H. AND WIRTH, N. 1993. The program-ming language Oberon-2. Manuscript. Institutfur Computersysteme, ETH Zurich.

MYERS, A. C., BANK, J. A., AND LISKOV, B. 1997. Pa-rameterized types for Java. In Proceedings of the24th ACM Simposium on Principles of Program-ming Languages (POPL’97).

ODERSKY, M. AND LAUFER, K. 1996. Putting type an-notations to work. In Proceedings of the 23rdACM Symposium on Principles of ProgrammingLanguages. 65–67.

ODERSKY, M. AND WADLER, P. 1997. Pizza into Java:Translating theory into practice. In Proceedingsof the 24th ACM Simposium on Principles of Pro-gramming Languages (POPL’97).

OHORI, A., BUNEMAN, P., AND BREAZU-TANNEN, V. 1989.Database programming in Machiavelli—a poly-morphic language with static type inference.SIGMOD Record 18, 2, 46–57.

POTTIER, F. 1998. Type inference in the presence ofsubtyping: from theory to practice. Ph.D. thesis,Universite Paris VII.

QIAN, Z. AND KRIEG-BRUECKNER, B. 1996. Typed OOfunctional programming with late binding. InProceedings of the 10th European Conferenceon Object-Oriented Programming, P. Cointe, Ed.Lecture Notes in Computer Science, vol. 1098.Springer-Verlag, New York, pp. 48–72.



RAJ, R. K., TEMPERO, E., LEVY, H. M., BLACK, A. P.,HUTCHINSON, N. C., AND JUL, E. 1991. Emer-ald: A general-purpose programming language.Softw. Pract. Exp. 21, 1 (Jan.), 91–118.

REHOF, J. 1998. The complexity of simple sub-typing systems. Ph.D. dissertation, DIKU, De-partment of Computer Science, University ofCopenhagen.

RICHARDSON, J. E., CAREY, M. J., AND SCHUH, D. T.1993. The design of the E programming lan-guage. ACM Trans. Prog. Lang. Syst. 15, 3 (July),494–534.

ROE, P. AND SZYPERSKI, C. 1997. Lightweight para-metric polymorphism for Oberon. In Proceedingsof the Joint Modular Languages Conference.

SARASWAT, V. 1997. Java is not type-safe. Avail-able electronically. URL: http://www.research.att.com/∼vj/bug.html

SCHMIDT, J. W. AND MATTHES, F. 1994. The DBPLproject: Advances in modular database program-ming. Inf. Syst. 19, 2, 121–140.

SEQUEIRA, D. 1998. Type inference with boundedquantification. Ph.D. thesis, Department ofComputer Science, University of Edinburgh.Also Technical Report ECS–LFCS–98–403.

SHANG, D. 1997. Transframe: The Annotated Ref-erence. Software Systems Research Laboratory,Motorola, Inc., Schaumburg, Illinois. Draft 1.4.

SQL 1999. Database languages—SQL. AmericanNational Standard for Information Technology.

ANSI/ISO/IEC 9075-1-1999, 9075-2-1999, 9075-3-1999, 9075-4-1999, 9075-5-1999.

STOUTAMIRE, D. AND OMOHUNDRO, S. 1996. TheSather 1.1 specification. Tech. Rep. TR-96-012,International Computer Science Institute atBerkeley. August.

STROUSTRUP, B. 1991. The C++ Programming Lan-guage. Addison-Wesley.

TAIVALSAARI, A. 1996. On the notion of inheritance.ACM Comput. Surv. 28, 3 (Sept.), 439–479.

THORUP, K. K. 1997. Genericity in Java withvirtual types. In Proceedings of the 1997European Conference on Object-Oriented Pro-gramming (ECOOP’97).

TRIFONOV, V. AND SMITH, S. 1996. Subtyping con-strained types. In Proceedings of the 3rd Inter-national Static Analysis Symposium. 349–365.Lecture Notes in Computer Science 1145.

TSICHRITZIS, D., NIERSTRASZ, O., AND GIBBS, S. 1992.Beyond objects: Objects. Int. J. Intel. Coop. Info.Syst. 1, 1 (Mar.), 43–60.

W3C 2002. XQuery 1.0 Formal Semantics. W3C.Working Draft 26. URL: http://www.w3.org/TR/2002/WD-query-semantics-20020326/.

WIRTH, N. 1983. Programming in Modula-2, 2nded. Springer-Verlag.

WRIGHT, A. K. 1993. Polymorphism for imperativelanguages without imperative types. Tech. Rep.TR93-200, Department of Computer Science,Rice University. February.

Received June 2000; revised December 2001; accepted May 2002
