University of Alb erta
Typ e System for an Ob ject Oriented
Database Programming Language
by
Yuri Leontiev
Technical Rep ort TR
Octob er
DEPARTMENT OF COMPUTING SCIENCE
University of Alb erta
Edmonton Alb erta Canada
University of Alb erta
Type System for an Object Oriented
Database Programming Language
by
Yuri Leontiev
A thesis submitted to the Faculty of Graduate Studies and Research in partial ful llment of the
requirements for the degree of Do ctor of Philosophy
Department of Computing Science
Edmonton Alb erta
Fall
Tomy parents Vladimir Vasilievitch Leontiev and Alla Davidovna Leontieva
Abstract
The concept of an ob ject oriented database programming language OODBPL is app ealing b ecause
it has the p otential of combining the advantages of ob ject orientation and database programming
to yield a p owerful and universal programming language design
A uniform and consistent combination of ob ject orientation and database programming how
ever is not straightforward Since one of the main comp onents of an ob ject oriented programming
language is its typ e system one of the rst problems that arise during an OODBPL design is related
to the development of a uniform consistent and theoretically sound typ e system that is su ciently
expressive to satisfy the combined needs of ob ject orientation and database programming
This dissertation presents the design of a typ e system suitable for ob ject oriented database
programming Thetyp e system has a unique combination of uniformity expressibility veri ability
and theoretically proven soundness It also p ossesses features that make it suitable for database
programming such as seamless integration of imp erativetyp es and features precise query typing
via union and intersection typ es separation among three abstraction layers providing a high degree
of co de reuse parametric p olymorphism extensibility and dynamic typ e analysis capabilities
In the pro cess of typ e system development a theoretical framework for dealing with typ e systems
that combine parametric and inclusion p olymorphism is established Due to its mo dular construc
tion this framework can b e easily extended and used b eyond the scop e of this dissertation Another
contribution of this work is an extensive analysis of existing and prop osed typ e systems from the
p oint of view of the set of requirements related to ob ject orientation and database programming
This research leads to the development of a uniform and theoretically sound OODBPL that
can successfully utilize the p ower inherent in b oth ob ject orientation and database programming
paradigms This will eventually lead to the development and implementation of a uniform ob ject
oriented database system that will use the OODBPL as its main programming and query engine
Acknowledgements
Iwould like to express my sincere thanks to my sup ervisors Dr Tamer Ozsu and Dr Duane Szafron
for their invaluable input constant supp ort and understanding This dissertation would not have
b een p ossible without their guidance
I am also grateful to the memb ers of my committee Dr Malcolm Atkinson Dr William Arm
strong and Dr Witold Pedrycz for manyvaluable comments and suggestions
Sp ecial thanks go to my Russian sup ervisor Vladimir Lvovitch Arlazarovandmy colleagues
Alexander Merkov and Marina Io nova Without their guidance and supp ort this work would not
have b een p ossible as I would not have had an opp ortunity to come to study at the Universityof
Alb erta I would also like to thank Dr Tony Marsland who help ed me come to this University
Thanks also go to the database research group and in particular to Boman Irani Iqbal Goralwalla
Kaladhar Voruganti Paul Iglinski and Wade Holst for manyinteresting helpful and insightful
discussions
Thanks to the University of Alb erta Department of Computing Science and the Killam Fund
for their nancial supp ort
My sup ervisors at Intuit Canada Ltd Andrew Smith and Drew LaHaie haveprovided me with
an opp ortunitytocontinue my studies while working full time for this company
Many thanks to my friends Igor Kolo dkin Igor Voronkov Oleg Verevka and Victoria Lohvin
Alexandr and Alina Litvak Andrey Zelnikov IlyaVodopyanov Andrey Maximov Vlad Alexiev and
Dolya Alexieva Anna Zolotova Ewgenii Gawrilow and Tatyana Gawrilowa Grigoriy Andronov
Dmitriy Makarov and Natalya Makarova Maxim Potashev Maria Schigoleva Dmitriy Khabirov
and Olga Chernova Evgenia Kashina and Kirill Oseledets Their friendship has supp orted me
throughout these years
I am grateful to my wife Marina for her love encouragement and understanding It is her supp ort
that gave me the strength to complete this work
I am indebted to my parents Vladimir Vasilievitch Leontiev and Alla Davidovna Leontieva for
their love and supp ort during this work and throughout myentire life This thesis is for them
Contents
Intro duction
Overview
Scop e and contributions
Organization
Requirements and Typ e System Survey
Terminology
Essential features of a typ e system
Ob ject oriented programming language requirements
Database programming language requirements
Ob ject oriented database system requirements
Summary of requirements
Related work
Typ e systems review
Conclusions
The Typ e System Design
Typ es and b ehaviors
The notion of a type
Interface sp eci cation and pro duct types
Behavior typ es
Mutable typ es
Parametric typ es and b ehaviors sp eci cation
Parametricity and subtyping
Parametricity and interface sp eci cation
Union and intersection typ es
Constrained sp eci cations
Subtyping and inheritance
Conclusions
Classesandfunctions
Classes
Sub classing and class extension
Ob ject creation and extent maintenance
Functions and asso ciations
Dispatch
Closures and typeif
Implementation typ es
Three layer design Advantages and applications
The basic typesystem
Ob ject typ es
Atomic types
Collection typ es
Conclusions
The Language and Typ echecking
Syntax and translation
The target language
The translation
Consistency
Notation
Lo cal monotonicity
Simplicity and the user typegraph
Typ e expansion
Constraint consistency
Global b ehavior consistency
Functional consistency
Dispatchconsistency
Entailment
Conclusions
The Typ e System Theory
Decidability
Finite evolution
Termination of expansion algorithm
Termination of attening algorithm
Termination of entailment algorithm
Typ es
Regulartrees
Subtyping
Entailment
Prop erties of entailment and attening algorithms
Constrained typ es
Subjectreduction
Static subsumption
Natural semantics
Execution state typing
Dispatch correctness
Sub ject reduction
Imp erativetypes
Extensions
Errors nulls and exceptions
Lo cal variables and dynamic scoping
Non lo cal returns
Handling ob ject creation
Discussion
Extensibility
Typ e system evolution
Engineering trade o s
Summary
Conclusions
Summary and contributions
Future research
Bibliography
A The Basic TIGUKATTyp e System
A Commonbehaviors
A Pro duct types
A Functional typ es
A Ob ject typ es
A Sp ecial typ es
A Atomic types
A Collection typ es
A Imp erativetypes
A Metatypes
A Class typ es and the metaclasses
B Implementation Notes
B Ob ject identi ers
B Multiple dispatch
B Implementation typ es and functions
B Adding p ersistence
C Mo dule System
C Information hiding and sharing
C Exportandimport
C Inner mo dules
C Name search
C Adding p ersistence
List of Tables
Typesystemindex
Typ e system features
Typ e system expressibility
Typ e system tests
Variance combination
List of Figures
Typ e system layers
Person typ e hierarchy
Stream types
Comparable types
Class typ e hierarchy
Shap e typ e hierarchy
TIGUKATtypes
TIGUKAT ob ject types
TIGUKAT atomic typ es
TIGUKAT collection types
Example user typ e graph G
Typing rules for the target language
Natural semantics of the target language
Typing rules for rt ob jects
C Mo dule data structures
C Name search
C Name search in the givenmodule
C External name search in the givenmodule
Chapter
Intro duction
Overview
From its early days ob ject orientation OO was considered one of the most in uential and useful
programming paradigms Its impact on research in virtually all areas of computing science can
only b e compared to that of relational algebra or that of the functional and logic programming
paradigms
Muchofthepower of ob ject orientation lies in the fact that it provides conceptual and mo deling
capabilities that allow it to express real world entities with relative simplicity Another source of
the app eal of ob ject orientation is its supp ort for incremental software construction provided in the
form of co de reuse
All these advantages were rst realized and exploited by the programming language PL research
community Starting with Simula and Smalltalk the development of ob ject oriented languages
has b ecome a landmark of programming language research in the last two decades
Another ma jor research area that exp erienced the impact of the ob ject oriented paradigm is the
area of database management systems DBMS The high mo deling p ower of ob ject orientation along
with its abstraction capabilities can make it one of the preferred paradigms in the developmentof
DBMSs designed to deal with complex data intensive applications such as CAD CAM multimedia
and o ce information systems
As b oth programming language and database system research areas exp erienced the impact of
the ob ject oriented paradigm so did their child the area of database programming languages
This relatively young research area is still a source of proli c research and development activity
much of this activity b eing concentrated on ob ject oriented database programming languages or
database programming languages with ob ject oriented features
Ob ject oriented database programming languages OODBPLs have the p otential to combine the
mo deling and software construction p ower of the ob ject oriented paradigm extensive and e cient
data storage and retrieval techniques of the mo dern database systems and the e ciency and p ower
of to day s programming languages in a single uniform framework
However OODBPLs haveyet to live up to their p otential Most of the mo dern OODBPLs are
simply ob ject oriented programming languages with the concept of p ersistence added to them They
do not provide the full p ower of database systems either in their data access mechanisms or in their
query capabilities Therefore the problems related to the design of an OODBPL that can combine
the p ower of its three constituent parts OO DB and PL are nowadays the topics of extensive
research activity
Both the mo deling and software construction p owers of ob ject oriented languages are ro oted in
their typ e and inheritance systems A prop erly designed rich and theoretically sound typ e system
can greatly increase the p ower of a language while a p o or in exible typ e system can render almost
all p ower inherent in the ob ject oriented paradigm useless
While the typ e system of an ob ject oriented language greatly a ects its characteristics the typ e
system of an OODBPL a ects its characteristics even more The reason for that is the presence
of di erent and sometimes contradictory requirements that are imp osed on the typ e system byan
OODBPL s database and programming language comp onents
The presence of two sets of requirements makes the developmentofatyp e system for an OODBPL
achallenging task It therefore comes as no surprise that no existing typ e system satis es the
requirements that are imp osed on OODBPLs
While the task of developing suchatyp e system is di cult it is also quite rewarding Apart
from the pro of of the validityofthevery concept of OODBPL the solution to this problem will
provide the designers of OODBPLs with a consistent and uniform framework that would greatly
facilitate the development of such languages in the future
Scop e and contributions
In this dissertation a typ e system for an ob ject oriented programming language is develop ed This
typ e system satis es a set of requirements that are placed on the typ e system by b oth database and
ob ject oriented language comp onents These requirements are compiled from several sources and
reviewed in terms of their relevance and necessity
An extensive review of existing typ e systems is conducted in order to nd out which of them
satisfy the requirements It is concluded that none of the reviewed typ e systems completely satis es
all the requirements and therefore the task of designing such a system is relevant and imp ortant
The discussion of the typ e system presented in this dissertation is broken down into three com
p onents the design principles the typ echecking and veri cation algorithms and the theoretical
framework that consists of the pro ofs of correctness of the presented techniques
One of the design principles used in the construction of the presented typ e system is the novel
principle of three layered language design The three layers are the interface layer the implemen
tation co de layer and the representation data layer This design principle provides additional
exibility in sp eci cation and use of typ es and facilitates b etter co de reuse A ma jor motivation
for the layered design is understandabilityofthetyp e system by programmers The system can
b e used at all the three layers the deep er the layer the more p ower it provides and the greater
complexityitinvolves Other ma jor design principles are substitutability parametricity veri abil
ity and soundness The source language showing the use of this design and the typ e system is also
presented This language can serve as a core for the development of a full edged OODBPL
Typ echecking and veri cation algorithms are based on a notion of typeconstraint entailment
A program to b e veri ed is transformed into a set of subtyping constraints and the task of the
typ e checker is to verify that these constraints admit a solution under certain assumptions Another
imp ortant asp ect of program veri cation is the validity of the dispatchmechanism Dispatch is the
pro cess of dynamically cho osing the function to execute at a call site dep ending on the typ es of actual
arguments The validity of dispatch is also tested byverifying entailment relationships b etween sets
of subtyping constraints Development of a correct and decidable typ echecking algorithm for a typ e
system as complex as the one describ ed here is one of the ma jor contributions of this work
In order to formally prove the prop erties of the presented algorithms a theory of subtyping and
the natural semantics of a simpli ed version of the language the target language are develop ed
Equipp ed with this theory pro ofs of decidability and correctness of the presented algorithms are
given
Thus prop erties of the presented typ e system include veri ability soundness and expressibility
Veri ability is understo o d as a provable termination of all the algorithms involved in the program
veri cation pro cess Soundness stands for the guarantee that a successfully typ echecked program
do es not generate typ e errors at run time Expressibility is the ability of the typ e system to express
various program and typ e structures The result of this research is applicable to the developmentof
p ersistent ob ject oriented typ e systems and languages and their theoretical underpinnings
Other research areas relevanttothedevelopment of an OODBPL but not discussed in this
dissertation include built in ob ject oriented query language and its optimization the p ersistence
mo del and the implementation of the language
Organization
The remainder of this dissertation is organized into vechapters Chapter presents the set of
requirements placed on the typ e system The requirements are discussed and a test suite of programs
designed to test the conformance of the typ e system to the expressibility and re exivity requirements
is develop ed An extensive review of existing and prop osed typ e systems is conducted The chapter
concludes with an evaluation of these typ e systems relativetotherequirements Chapter is devoted
to the description of the design principles and decisions made during development of the presented
typ e system It highlights various design choices and explains the ones that were made The language
and the typ echecking and veri cation algorithms are presented in Chapter Chapter deals with
the formal asp ects of the presented typ e system The pro ofs of the decidability and correctness
results as well as the natural semantics of the simpli ed target language used for typ echecking are
presented in this chapter Finally Chapter concludes with a summary of contributions and outlines
directions for future research
App endix A presents an example of usage of the concepts develop ed in this dissertation for
an OODBPL based on a uniform b ehavioral ob ject mo del Pet App endix B provides a set of
implementation notes and design decisions made during a preliminary implementation of a compiler
and the run time system for the TIGUKAT p ersistent programming language App endix C presents
a mo dule system design for the language While not directly related to the typ e system itself the
mo dule system provides supp ort for additional information hiding and sharing
Chapter
Requirements and Typ e System
Survey
The purp ose of this chapter is to answer two questions What are the requirements that a mo dern
typ e system for an ob ject oriented database programming language should satisfy and Are there
anytyp e systems develop ed to date that satisfy these requirements
In order to answer the rst question the set of requirements put forth in the literature for
typ e systems Section mo dern ob ject oriented programming languages Section database
programming languages Section and ob ject oriented database systems Section by the
leading researchers in these areas will b e considered Then the set of required typ e system features
will b e extracted The resulting combination of requirements is presented in Section Also
presented is the test suite that is used later to evaluate the existing typ e systems reviewed in this
chapter
Section presents an extensive review of more than languages and typ e systems These typ e
systems are evaluated with resp ect to the requirements and the test suite presented in Section
The result of this extensive analysis shows that while each of the requirements is satis ed byat
least one typ e system no typ e system satis es all of them It also enables the identi cation of the
mechanisms that lie b ehind the strengths and weaknesses of the currenttyp e systems The knowledge
obtained this way will b e used in subsequent sections to aid in the design and development of the
typ e system that satis es all of the ab ove requirements which is the primary goal of this work
Terminology
Let us start by establishing some terminology to b e used throughout the rest of this chapter This
is necessary as many of the terms used in the ob ject oriented language researchareahavenoclear
de nition and are used di erently by di erent authors Most of the terminology b elow comes from
Car BP
Ob ject A primitive term for a data item used to mo del a concept or a real world entity
Message A part f of an invo cation x f anidenti cation for a related set of metho ds
Function name Apartf of invo cation f x also can b e termed as a message not asso ciated with
anytyp e Sometimes called a free oating function
Metho d A pro cedure to b e executed when an ob ject is sent an appropriate message
Function A pro cedure to b e executed when a function invo cation is requested Function relates
to a function name the same way a metho d relates to a message
These de nitions are not necessarily universally accepted but they are used consistently throughout this disser
tation
Interface typ e A description of messages applicable to an ob ject
Implementation representation typ e A description of an ob ject s structure
Typ e A shorthand for interface or implementationtyp e or b oth dep ending on the context
Mutable ob ject typ e Atypeofanobjectthatiscapableofchanging its state at run time For
example variables and arrays are mutable ob jects These typ es are sometimes called imperative
types
Parametric parameterized typ e message function Atyp e message function that de
scrib es a family of typ es messages functions by using an explicit parameter s For exam
ple
type T List X
getAt T Integer X
Constrained typ e A parametric typ e that places a constraint on its parameter s The mecha
nism that allows a programmer to sp ecify suchatyp e is called bounded quanti cation For
example
type T PersonList X where X subtype of T Person
sp eci es a constrained typ e T PersonList
Intersection greatest lower b ound typ es An intersection of a set of typ es is a typ e that
represents the greatest lower b ound of the set in the typ e lattice Intersection typ es are useful
for typing of set theoretic op erations and queries
Inheritance Amechanism for making one interface or implementation typ e from another A
single inheritance requires that a typ e has at most one immediate ancestor parent in the
inheritance chain multiple inheritance lifts this restriction
Interface subtyping A partial order on interface typ es An interface typ e A is a subtyp e of
another interface typ e B when an ob ject of the interface typ e B can b e thoughtofasanobject
Student is a subtyp e of T Person since every student of the interface typ e A e g a typ e T
can b e thought of as a p erson
Implementation subtyping co de reuse A partial order on implementationtyp es An imple
mentation typ e A is a subtyp e of another implementation typ e B if it is p ossible to use co de
written for A to manipulate ob jects that have the implementation typ e B
First class ob ject An ob ject that is capable of receiving messages
Non rst class ob ject value An immutableobjectthatlacks the ability to receive messages
Traditionally it is assumed that values havenointerface just a set of op erations de ned on
them In this dissertation such a set of op erations will b e considered an interface of a value
Primitive atomic typ e A primitivetyp e is a typ e of basic primitive system de ned ob jects
or values suchasintegers reals characters etc Primitivetyp es usually have a sp ecial status
in non uniform systems and languages
Soundness of a typ e system Inability of a successfully typ echecked program to pro duce run
time typ e errors Sometimes divided into static and dynamic soundness The latter makes
sense for languages with dynamic typ e checking and assures that run time typ e errors will b e
caught
Veri abilityofatyp e system decidable typ echecking The abilityto verify that a pro
gram do es not contain typ e errors with resp ect to a particular typ e system equivalently
the presence of a decidable typ echecking algorithm Note that veri ability do es not imply
soundness For example the language Ei el Mey has a decidable typ echecking algorithm
but a successfully typ echecked program can pro duce run time typ e errors
Substitutability A prop ertyofatyp e system language that guarantees that an ob ject of a
Person is a subtyp e can b e used everywhere the ob ject of its sup ertyp e can e g if a typ e T
sup ertyp e of T Student then a student can b e legally used wherever a p erson can b e
Dispatch A pro cess of nding out at run time which method of a particular message to execute
Single dispatch bases its decision on the typ e of the rst argument receiver only while multiple
dispatch takes into accounttyp es of other arguments as well The term static dispatch will b e
used to refer to a compile time pro cess of metho d determination
Static dynamic typing typ echecking Static typ echecking is done at compile time while dy
namic typ echecking is done at run time
Implicit explicittyping Languages with explicit typing require the programmer to insert typ e
annotations in the program Languages with implicit typing infer the typ es of expressions
without any help from the programmer Intermediate approaches are also p ossible
Inclusion p olymorphism This term refers to a combination of subtyping and substitutability
Parametric p olymorphism Parametric p olymorphism is present when parametric sp eci cations
e g parametric typ es are supp orted
Covariance contravariance novariance Covariance means that changes in a particular typ e
are parallel to the direction of the typ e hierarchy In the following example the result typ e of
the metho d getAt changes co variantly asitisT Person in de nition which o ccurs in the
typ e T PersonList and T Student a subtype of T Person in de nition which o ccurs in
the typ e T StudentList a subtype of T PersonList
type T Student subtype of T Person
type T PersonList
getAt T Integer T Person
type T StudentList subtype of T PersonList
getAt T Integer T Student
The reverse direction is termed as contravariant Novariance forbids anytyp e changes along
the typ e hierarchy In this example the argumenttyp e int changes novariantly i e do es not
change at all
The terms class and subclassing are delib erately avoided in this chapter as they are to o overloaded
In ob ject oriented literature the term class is used to denote a mechanism for ob ject construction
an equivalent of an implementationtyp e an equivalentofaninterface typ e a set of ob jects satisfying
a particular condition or some combination of the ab ove four notions The de nition of subclassing
is equally overloaded
Also the term type is quali ed as b eing either interface typ e or implementation typ e This will
prove useful when considering typ e systems where the twotyp e notions are distinct
Essential features of a typ e system
The ma jor goals of a typ e system in to day s programming languages and database systems include
Car Car BP
Provide a programmer with an e cientwayofcatching programming errors before a program
or a part of it is actually executed This is often considered to b e the ma jor ob jectiveofa
typ e system in the programming language community
Serve as a data structuring to ol for design and mo deling purp oses Many design technologies
that have emerged through the past decade rely partially or fully on typ e systems to provide
a convenient design and do cumentation framework for a system development pro cess This is
esp ecially true of ob ject oriented design technologies This is often considered to b e the ma jor
goal of a typ e system in the database community
Provide a convenient framework for program maintenance This includes do cumentation at
the pro duction stage of program evolution as well as the ability of a programmer to understand
the functionalityandinterfaces of a completed pro duct
Provide su cient information for optimization purp oses The information provided by the typ e
system can b e used by an optimizing compiler interpreter or a query optimizer in p ersistent
systems to improve the e ciency of a program
In order for a compiler or interpreter to b e able to typ echeck a program or a part of it there
must exist a typechecking algorithm Existence of such an algorithm for a given typ e system is
termed as veri ability of the typ e system Thus a typ e system should b e veri able It is preferred
that a typ e system b e decidably veri able however one mayhave to put up with an undecidable
typ e system just as one puts up with undecidable programs if enough expressivepower is desired
BP The veri ability prop erty also implies that a typ e system should b e provably sound i e
there should exist a formal pro of that a successfully typ e checked program do es not generate any
typ e errors at run time
If a compiler nds a typ e error and rep orts it to a programmer the latter should have su cient
information to b e able to understand the reason for the typ e error in order to correct it Thus the
typ e system should b e transparent
Atyp e system should also b e enforceable in order to prevent an execution of typ e incorrect
programs This implies that programs have to b e written with as muchtyp e information as p ossible
to prevent false alarms
Finally a typ e system should b e extensible This requirement stems from the fact that none of
the existing typ e systems were found to b e satisfactory for all p ossible applications Therefore the
chance that anynewtyp e system will satisfy al l application domains is remote If a typ e system
can not b e extended it will so oner or later b e abandoned for a typ e system that can adapt to new
application requirements Switching from one typ e system to another is extremely costly b oth in
terms of p eople resources that have to b e reeducated and in terms of data conversion costs
Ob ject oriented programming language requirements
Pure ob ject oriented programming languages p ose some sp eci c requirements on their typ e systems
These requirements will b e constructed by considering features essential for pure ob ject oriented
languages and reformulating them in terms of typ e system features
To b e called a pure object oriented language a language should p ossess at least the following
prop erties most of the following is b orrowed from TNG
Much of the discussion b elow is b orrowed from Car
Some of the features listed here are advo cated in TNG as absolutely necessary for future ob ject oriented
languages
Encapsulation This prop erty is usually considered as one of the characteristic features of
ob ject oriented languages and greatly facilitates co de reuse It refers to the ability of a language
to shield internals of an ob ject implementation from outside access
Inheritance This is a characteristic prop erty of ob ject oriented languages as well The inher
itance mechanism promotes and facilitates well structured software design and reusabilityof
the co de Multiple inheritance is highly desirable as its absence leads to clumsy or limited
typ e sp eci cation in some imp ortant cases
Uniformity Primitivevalues integers etc typ es and messages metho ds should b e rst
class ob jects If this requirement is not satis ed the language will have to handle the
non ob ject entities in some non ob ject oriented way and will therefore not b e purely ob ject
oriented Note that the existence of metho ds that are able to op erate on typ es and other
metho ds is a consequence of this prop erty This is also advo cated in Hau
Ob ject access and manipulation uniformity An ob ject can only b e manipulated by metho ds
de ned for it Together with uniformity this prop ertyprovides for purely ob ject oriented
programming
Metho d uniformity This refers to the absence of distinction b etween stored and computed
metho ds or equivalently the absence of public instance variables This requirementisimpor
tant as its violation breaks encapsulation and may e ectively hinder the usefulness of the co de
reusability provided by inheritance
Separation b etween interface and implementation inheritance sometimes termed as separation
between typ e and class hierarchies This is actually a consequence of encapsulation inheri
tance and ob ject manipulation uniformity Additional arguments in favor of such separation
can b e found in LP Cas Tai BLR LOS
Multi metho ds multiple dispatch This refers to the ability of a language to use typ es of all
arguments during dispatch Traditionally onlythetyp e of the rst argument the receiver is
used This prop erty of the language is essential to adequately mo del binary metho ds BCC
Cas LM FM and certain ob ject oriented design patterns BLR
Using these requirements for pure ob ject oriented languages it is nowpossibletoformulate desirable
features of typ e systems for such languages These requirements are
Inheritance mechanisms for b oth interface and implementation inheritance This requirement
is a direct consequence of the language requirements and ab ove
Typ e system re exivity This is necessary to ensure uniformity of the language requirement
since typ es classes have to b e ob jects Since every ob ject has a typ e typ es and classes need
to havetyp es as well Thus the typ e system needs to b e re exive
Metho d typ es This is also a consequence of uniformity Indeed since metho ds havetobe
ob jects to ensure uniformity they will havetyp es Moreover when metho ds are manipulated
as ob jects e g passed as arguments to other metho ds their typ es should b e descriptive
enough to ensure the validityoftyp e checking
Metho d uniformity at the typ e level no distinction b etween typ es of stored and computed
metho ds This is a direct consequence of the language requirement
Supp ort for multi metho ds multiple dispatch This is a consequence of the language require
ment
Another desirable feature of an ob ject oriented typ e system is substitutability at least for interface
inheritance This prop erty is essential to achieve one of the primary goals of the ob ject oriented
paradigm co de reuse
Database programming language requirements
Database programming languages DBPLs p ossess their own set of distinguishing features that
p oses additional requirements on typ e systems The approach of the previous subsection will b e
used to derive the typ e system features from the following list of necessary features of a p ersistent
language that is taken from AB AM
Persistence indep endence the form of the program is indep endent of the longevity of data
the program op erates up on This is necessary to provide seamless integration b etween the
database and the language and to signi cantly reduce the amount of co de necessary to deal
with p ersistent data
Orthogonalityoftyp e and p ersistence data of all typ es can b e p ersistentaswell as transient
This is an aid to data mo deling as it ensures that the mo del can b e indep endent of the longevity
of data It also eliminates the need of explicit p ersistent to transientdataconversions
User de ned typ e constructors This requirement is due to the necessity of mo deling new
p otentially complex data structures in a uniform and consistent manner
Information hiding also known as encapsulation Encapsulation allows for data mo deling at
a higher more abstract level as it hides the implementation details and gives the programmer
an ability to deal with abstract interfaces rather than concrete data structures It greatly
facilitates mo deling co de reuse and comp onentintegration
Polymorphism parametric inclusion or b oth Parametric and inclusion p olymorphisms make
the sp eci cations more succinct and precise They also allow for a signi cant reduction in the
amount of co de that needs to b e written to sp ecify and implement a particular data mo del
as a signi cant p ortion of the sp eci cations are reused via genericityachieved by the use of
p olymorphic constructs
Static and strong typing with provisions for partial typ e sp eci cation which necessitates the
presence of a typ e mechanism similar to one formed bytyp e constructor dynamic and op erator
typecase This is necessary in order to deal with data that come from a p ersistent store whose
structure is only partially known at the time the program is written An example of a program
that requires such capabilities is a generic database browser that is supp osed to work on any
database indep endently of its structure
Incremental program construction and mo dularity This principle ensures that most of the
program mo di cations can b e done lo cally without a ecting the rest of the co de While this
prop ertyisvery imp ortant for programming languages in general it is even more imp ortant
for database programming since databases tend to exist and evolve for extensive p erio ds of
time As a database evolves the programs designed to op erate on it havetoevolveaswell
Mo dularity is one of the ma jor features that signi cantly reduce the overhead of suchan
evolution
Query facilities One of the main reasons b ehind the success of the relational data mo del was
its ability to supp ort declarative simple yet p owerful data access query languages In order
for ob ject systems to b e successful they must provide querying capabilities equal or exceeding
those of the relational systems
Ability of a program to deal with state change This requirement is necessary as p ersistent
data outlive the program and if a program is not able to change data the state of p ersistent
data will never change
From this list of requirements the following prop erties of the typ e system can b e derived
Features not related to typ e system are dropp ed from the list
Typ es classes in the typ e system should not b e sp eci ed as either p ersistent or transient
This is the DBPL requirement reformulated in terms of typ e system terminology
User de ned typ e constructors This is the same as the DBPL requirement
Encapsulation This follows from the DBPL requirement
The presence of parametric typ es This follows from the DBPL requirements parametric
p olymorphism and It is also desirable to handle b ounded constrained parametric typ es
as it increases the mo deling p ower of the typ e system
Possibility of partial typ e sp eci cation and dynamic typ e checking This follows from the
DBPL requirement
Veri able and sound typ e system as a consequence of the DBPL requirement
Incremental typ e checking as a consequence of the DBPL mo dularity requirement
The ability of the typ e system to correctly typ e declarative queries This stems from the
DBPL requirement According to BP this requires that the typ e system can supp ort
union least upp er b ound typ es
The ability of the typ e system to deal with typ es of mutable ob jects later referred to as mutable
ob ject typ es and assignment This is a direct consequence of the DBPL requirement
In addition to the ab ove KCMS advo cates the use of re ection in p ersistent ob ject systems
The combination of ob ject orientedness and p ersistence p oses some additional requirements de
scrib ed in the next subsection
Ob ject oriented database system requirements
A list of features needed or desirable in ob ject oriented database management systems OODBMS
and the rationale b ehind it are given in ABD This is the most comprehensiveofsuch lists
published so far
The following list is the part of it that is related to typ e system issues It contains the additional
requirements to those already listed in the previous subsections
Complex ob jects orthogonal typ e constructors should include at least sets tuples and lists
This is necessary to ensure that the mo deling p ower of the system is su cient to deal with
mo dern applications such as CAD CAM medical and geographical information systems
Extensibility user de ned and system typ es should have the same status and the user should
b e able to add new primitive typ es to the system This is also due to the necessity of dealing
with new demanding application areas It is imp ossible to anticipate all the data typ es that will
b e required to mo del the data structures in those areas since some of them are yet to emerge
By providing the same status to system and user de ned typ es the system guarantees that its
capabilities are not decreased when it is applied to a new application domain Also advo cated
in MS
Views A view is in a sense an ability to transparently change the app earance of data for
di erent users clients The imp ortance of this concept as well as its usefulness and p ower
have b een convincingly demonstrated byyears of exp erience obtained by the researchand
industrial communities in dealings with relational databases
Some issues often considered as de ciencies of ob ject oriented systems for example in Kim but deemed
optional in ABD are listed here as mandatory The reason for that is the understanding that if ob ject oriented
databases are to b e the next step in the database development they should utilize the advances already made in
relational databases
Dynamic schema evolution This requirement is based on the necessitytomaintain and
change the database structure over extensive p erio ds of time While it is sometimes p ossible
to create a completely new database with a new schema and migrate data to it this approach
is usually quite exp ensive and results in a substantial down time This is often not acceptable
in large distributed applications such as air tra c control systems Dynamic schema evolution
makes it p ossible to change a database structure transparently to its users
These additional requirements havetobetaken into account when designing a typ e system for a
pure ob ject oriented database programming language Next these requirements will b e summarized
and a short overview will b e given
Summary of requirements
The following is the compilation of all typ e system requirements presented so far The categorization
of the requirements presented here is sub jective but it do es provide a useful structure to the extensive
set of requirements compiled so far Each requirement listed b elowcontains a reference to the section
where it has b een intro duced and explained
Theoretical requirements
a Veri ability preferably decidable and provable soundness of the typ e system These
features are necessary for the typ e system to b e useful for program veri cation see
Section and Section
Inheritance requirements
a Inheritance mechanisms for b oth interface and implementation inheritance Section
b Substitutability prop erty at least for interface inheritance Section
Expressibility requirements
a Metho d typ es Section
b Parametric typ es Section
c Orthogonal typ e constructors at least sets tuples and lists Section
d Encapsulation Section and Section
e The ability of the typ e system to deal with mutable ob ject typ es and assignment Sec
tion
f The ability of the typ e system to correctly typ e multi metho ds Section
g The ability of the typ e system to correctly typ e SQL like queries Section
Uniformity requirements
a Extensibility user de ned and system typ es should have the same status Section
b Typ es classes in the typ e system should not b e sp eci ed as either p ersistent or transient
Section
c Metho d uniformity at the typ e level no distinction b etween typ es of stored and computed
metho ds Section
Re exivity requirements
a Typ e system re exivity Section
Dynamic requirements
a Possibility of partial typ e sp eci cation and dynamic typ e checking Section
b Provisions for schema evolution Section
Other requirements
a Transparency of the typ e system for a programmer Section
b Incremental typ e checking Section
c The ability to de ne views in a typ e safe fashion Section
Some of the ab ove requirements are complimentary while others are contradictory Most notably
decidable veri cation con icts with re ection as shown for example in Car b Also enforce
ability con icts to a degree with partial typ e sp eci cation Another con ict can b e seen in that the
complexity of the typ e system that satis es the expressibility requirements ab ove will most probably
make the resulting typ e system much less transparent for a programmer than one would likeittobe
CMM also identi ed a con ict b etween substitutability mutable typ es and static typ e safety
The presence of suchcontradictory requirements makes the task of designing a typ e system that
satis es them particularly di cult
The following is a set of test programs that a typ e system should b e able to typ e correctly
These tests are primarily designed to test typ e systems for their expressibility as this is the most
di cult set of requirements to check however the last test is the test for re exivity and uniformity
The programs are written in an ob ject oriented pseudo language
These programs are designed to test known problem areas of ob ject oriented typ e systems They
are also used to verify the ability of the typ e system to consistently and orthogonally combine
parametric and inclusion p olymorphism with mutable typ es and assignment This has to b e done
b ecause soundness veri ability parametricity substitutability andmutable typ es are all among the
requirements for an OODBPL typ e system
Many of the expressibility tests are adapted from BP which presented a b enchmark for testing
typ e system expressibility However their b enchmark was designed to measure the expressibilityof
atyp e system for an ob ject oriented programming language and not for an ob ject oriented database
programming language Thus some tests related to the additional expressibility requirements pre
sented ab ovewere added
The requirement related to mutable ob ject typ es and assignmentistestedbyeach of the tests
b elow This is done in order to verify that a typ e system can deal with mutable typ es in combination
with parametric and inclusion p olymorphisms This is a well known problem area in ob ject oriented
typ e systems CMM
Person and T Child with metho d getAge that returns T Integer when applied to a Typ es T
p erson and T SmallInteger when applied to a child PERSON
type T Integer
type SmallInteger subtype of 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
Note that the terms test and test program are not used here in the traditional software engineering sense
The programming language examples are used to illustrate the tests and not to suggest the necessary language
constructs
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 that subtyping do es not necessitate the absence of changes
Surprisingly there is a considerable numb er of languages that do not allow any changes while
inheriting only additions This signi cantly limits the p ower of the typ e system and forces
the designer to use less sp eci c typ e information
Typ es T Point and T ColorPoint with equality on b oth The equalitybetween color p oints
should takecolorinto account while the equalitybetween two p oints or b etween a p ointand
a color p oint should ignore it POINT
type T Point
equal T Point p T Bool implementation equal
type T ColorPoint subtype of T Point
equal T ColorPoint p T Bool implementation equal
T Point p new T Point
T ColorPoint p new T ColorPoint
p equal p should call equal
p equal p should call equal
p equal p should call equal
p equal p should call equal
p new T ColorPoint
p equal p should call equal
p equal p should call equal
p equal p should call equal
p equal p should call equal
This test is adapted from BP It tests the typ e system s abilitytodealwith binary methods
awell known problem area in ob ject oriented typ e systems BCC FM
Typ es T Number with unrelated subtyp es T Real and T Radix and T Date with comparison
metho ds such that comparing twonumb ers or two dates is legal while their cross comparison
is not All metho d co de b elow except for the co de for the metho d less should b e 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 less
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 less
T Date d d
T Number n n
T Radix radixVar xF
T Real realVar
d d
n realVar
n radixVar
n less n should call less
n greater n should eventually call less
n less realVar should call less
n greater radixVar should eventually call less
d less d should call less
d greater d should eventually call less
d less n should cause compile time error
n less d should cause compile time error
This is an additional test for binary metho d handling It tests whether the subsumption
prop ertycanbemaintained in the presence of binary metho ds This test is necessary due
to the fact that some approaches to the binary metho d problem most notably matching
BSG BFP abandon substitutability and substitutability is one of the requirements for
an OODBPL typ e system
Parametric input output IOstream typ e hierarchysuch that the three typ es are parameterized
bythetyp e of ob jects readable writable to from a particular stream with T IOstream b eing
a subtyp e of b oth input and output stream typ es STREAMS
type T InputStream covarX
get X
isEmpty T Bool
type T OutputStream contravarX
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 compile time error
cp iscp get should be Ok
osp put p should be Ok
oscp put p should cause compile time error
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 compile time error
iscp ioscp should be Ok
osp iosp should be Ok
osp ioscp should cause compile time error
oscp iosp should be Ok
oscp ioscp should be Ok
This test is designed to verify that a combination of parametric and inclusion p olymorphism
in the typ e system do es not adversely a ect either of them In other words it tests the
orthogonality of the two p olymorphisms The presence of b oth parametricity and inclusion
p olymorphism subtyping substitutability in the typ e system is among the requirements
compiled earlier The unrestricted combination of the two p olymorphisms is known to b e
di cult DGLM BOSW c
Sorting of arbitrary ob jects under the constraint that all the ob jects have a comparison metho d
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
implementation
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 compile time error
lp sort ln should cause compile time error
ln sort lp should cause compile time error
This test is due to BP It is designed to verify the abilityofthetyp e system to deal with
b ounded quanti cation of the form for all typ es satisfying a given condition This is yet
another asp ect of the binary metho d problem It also tests the ability of the typ e system to
provide a link b etween parametricity and subtyping
Generic sort with a comparison metho d as a parameter The generic sort can b e applied to
a set of any ob jects provided that an appropriate comparison metho d is supplied 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
implementation
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 cause compile time error
This test is also from BP It is designed to verify that the typ e system is capable of
combining parametricity metho d typing and substitutability
A single linked list no de typ e and a double linked list no de typ e where the second typ e inherits
from the rst one A single linked list no de typ e is a recursively de ned typ e with a mutable
attribute that represents the list no de linked to the given one A double linked list no de typ e
has an additional mutable attribute to represent the second link The typ e system should not
allow links b etween di erentnodetyp es
Note that in this example the double linked no de typ e is not a subtyp e of a single linked no de
typ e however the typ e system should b e exible enough to allow co de reuse b etween them
The co de sample uses the keyword extends in order to describ e this relationship b etween
typ es LIST
type T LinkedListNode
selftype next
getNext selftype implementation return next
attach T LinkedListNode node
implementation attach
type T DoubleLinkedListNode extends T LinkedListNode
selftype prev
getPrev selftype implementation return prev
attach T DoubleLinkedListNode node
implementation attach
T LinkedListNode lln lln
T DoubleLinkedListNode dlln dlln
Initialization of list node variables
lln dlln should cause compile time error
lln lln should be Ok
lln attach lln should call attach
dlln attach dlln should call attach
lln attach dlln should cause compile time error
dlln attach lln should cause compile time error
This test is also adopted from BP It checks whether the typ e system supp orts co de reuse
beyond that provided by subtyping In other words it checks if co de reuse is p ossible b etween
typ es that are not in a subtyping relationship with each other Situations analogous to the
one describ ed in this test o ccur frequently when dealing with mutable typ es
Set union and intersection for immutable 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 sp sp
T Set T Student ss ss
Initialization of set variables
sp sp union sp should be Ok
sp sp union ss should be Ok
sp ss union sp should be Ok
sp ss union ss should be Ok
ss sp union sp should cause compile time error
ss sp union ss should cause compile time error
ss ss union sp should cause compile time error
ss ss union ss should be Ok
sp sp intersection sp should be Ok
sp sp intersection ss should be Ok
sp ss intersection sp should be Ok
sp ss intersection ss should be Ok
ss sp intersection sp should cause compile time error
ss sp intersection ss should be Ok
ss ss intersection sp should be Ok
ss ss intersection ss should be Ok
This test is designed to verify that set op erations used in SQL like declarative queries can
b e successfully and precisely typ ed This is necessary to ensure seamless integration of such
queries into the language
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
T SmallInteger si
i apply getAge p should be Ok
i apply getAge c should be Ok
si apply getAge p should cause compile time error
si apply getAge c should be Ok
This test is analogous to the calculus test presented in BP it di ers in that this test
also includes assignment It is designed to verify the abilityofthetyp e system to deal with
metho d typ es and uniformly treat metho ds as ob jects in the system
General database browser The browser should b e able to deal with databases that havean
unknown schema BROWSER
printNumber T Number num implementation
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
otherwise
print Something else
root getAge should cause compile time error
printNumber root getAge should cause compile time error
The given co de only tests the ability of the typ e system to deal with dynamic typ e information in a typ e safe
manner A complete browser would also require the ability to examine typ e structure of previously unknown typ es
This test checks the abilityofa typ e system to handle partial typ e sp eci cations and dynamic
typ e checking Both are on the list of requirements for an OODBPL typ e system
This set of requirements and tests will b e used in the next section to evaluate existing languages
and typ e systems
Related work
In this section typ e systems of many current languages as well as theoretical developments in the
area will b e reviewed These typ e systems and languages are listed in Table The table gives
references and pages in this dissertation where a given system is reviewed
The comparison b etween the typ e systems is presented in Table Table and Table
Not all of the languages and systems listed in Table are present in these tables Typ e systems
that are sup erseded by other typ e systems reviewed in this section languages that havenostatic
typ e systems and incomplete typ e systems are excluded from the review tables
Table lists features of the reviewed typ e systems that corresp ond to the requirements listed
in Section Veri ability is understo o d as the presence of a decidable typ e checking algorithm
Static soundness means that a successfully typ echecked program do es not pro duce errors at run time
while dynamic soundness means that the program rep orts al l p ossible typ e errors at run time in a
well de ned and predictable manner Static soundness is strictly stronger then dynamic soundness
The column uniformity atomics means that ob jects of primitive atomic typ es have the same rights
as ob jects of user de ned typ es The column uniformity methods refers to the ability of a language
to treat metho ds or messages or b oth as ob jects Re ection typecase indicates the abilityofa
language to deal with dynamic typ e checking in a typ e safe manner Finally re ection evolution
shows whether a given language supp orts incremental typ e system evolution
Table compares various asp ects of typ e system expressibility The rst two columns indicate
whether a given typ e system has a notion of subtyping shows what kind of subtyping structural
implicit or user de ned explicit it supp orts and what kind of inheritance single or multiple
the typ e system has The third column shows whether the typ e system supp orts metho d function
typ es The fourth column addresses the issue of dispatch single or multiple in the given typ e
system Columns through deal with parametricity and its relationship with subtyping Column
indicates whether a given typ e system supp orts parametric typ es Column shows if a typ e system
can deal with constrained parametric typ es Positive indication in column means that a typ e
system makes it p ossible for di erent parametric typ es formed using the same typ e constructor
to have a subtyping relationship with each other for example T Set T Person is a subtyp e of
T Set T Student Column indicates whether the typ e system is capable of sp ecifying subtyping
relationships b etween parametric typ es with di erent typ e constructors e g T List T Person is
Set T Person Column is an indication of the abilityofatyp e system to deal a subtyp e of T
with mutable typ es This indication is negative for typ e systems of purely functional languages
Column shows whether a typ e system supp orts intersection greatest lower b ound typ es
Finally Table demonstrates the p erformance of the reviewed typ e systems on the test suite
From the analysis of the results presented in Table it can b e concluded that languages Mini
Cecil and Transframe rate the b est on the test suite However none of them has provably sound
typ echecking in fact typ echecking Mini Cecil is likely to b e undecidable Lit Of the systems
with sound and veri able typ e checking the most impressive is Sather however its typ e system
lacks multiple dispatch and union typ es Soundness of Sather typ e system has not b een formally
proven Almost all theoretical typ e systems show similar p erformance on the test suite
Sound typ e checking substitutability parametricity metho d typ es and multi metho ds app ear
together in only one typ e system that of ML However ML as well as most ML clones severely
restricts usage of mutable typ es and do es not deal well with certain asp ects of binary metho ds and
parametricity failed tests COMPARABLE and STREAMS
Due to the enormous numb er of languages constantly b eing develop ed by the scienti c community this review
has to b e incomplete However every e ort has b een made to include known languages with interesting typ e system
features or their analogs Thus I hop e that none of the essential typ e systems are left out
Table Typ e system index
References Reviewed on page
C Str
E RCS
O AG
O LRV
Java AG DE Sar
Generic Java GJ BOSW c BOSW a BOSW b
Java parametric extension JPE MBL
Pizza OW AFM
Virtual typ es in Java JVT Tho BOW
ODMG OQL CBB
Mo dula Wir
DBPL SM
Mo dula LML
Mo dula Har
Ob eron MW RS
Lago ona Fra
Theta DGLM
Ada Ada
Ei el Mey
Sather SO
Emerald RTL
BETA MMPN
VML KT
Napier MBC
Smalltalk GR
Strongtalk BG
Cecil Cha Cha b
BeCecil CL CL
Mini Cecil Lit
Transframe Sha
CLOS BDG
Dylan App
TM BBdB
ML MTH Wri
Machiavelli OBBT BO
Fib onacci AGO
ML BM b BM a
Constrained typ es in ML AWL AW Pot Reh
Constrained typ es in Erlang MW
calculus CGL
PolyTOIL BSG BSG
Lo op ESTZ EST b EST a
TL MS MMS
TooL GM
TOFL QKB
Table Typ e system features
Soundness Separation b etween Uniformity Reflection
Typ e system Verifiability Static Dynamic interface and Substitutability Atomics Metho ds Typ ecase Evolution
implementation
C
E
O
O Unknown Unknown
Java Core only
GJ Unknown
JPE Unknown
Pizza
JVT Unknown
ODMG Unknown Unknown
DBPL Unknown Unknown n a n a
Mo dula Unknown Unknown
Mo dula Unknown Unknown
Ob eron Unknown Unknown
Theta Unknown Unknown Unknown
Ada Unknown Unknown
Sather
Emerald Unknown Unknown
BETA Unknown
Napier n a n a
Strongtalk Unknown Unknown
Cecil Unknown
BeCecil Unknown Unknown Unknown
Mini Cecil Unknown Unknown Unknown Unknown
Transframe Unknown Unknown
TM Unknown n a
ML n a n a
Machiavelli n a
Fib onacci n a
ML n a
PolyTOIL n a
Lo op n a
TL Unknown Unknown Unknown
TooL Unknown Unknown n a Unknown
TOFL n a
Except for covariant arrays whichhave b een kept in Pizza only for backward compatibilitywithJava
These features are based on modules packages fragments rather than on types
Substitutabilityworks for p ointers and references only
For ob ject typ es only
Even though a typ e can b e examined dynamically in O typ echecking do es not take this into account
Classes implementation typ es only
Evolution is typ e unsafe
The test STREAMS proved to b e the most di cult one This is surprising as the test outlines
the situation that o ccurs in almost every language dealing with I O op erations on a relatively high
level Only the typ e systems of Emerald and Mini Cecil where able to pass this test however none
of these typ e systems has a pro of of soundness
Overall typ e systems with nice theoretical prop erties show only mo derate p erformance on the
test suite while typ e systems that p erform well on tests lack a theoretical basis
The rest of this section presents a detailed review of various typ e systems The index of these
typ e systems is found in Table
Typ e systems review
C Str is currently one of the most widely used ob ject oriented programming languages C
typ es combine the characteristics of interface and implementation typ es in that they de ne b oth the
interface and the structure of their ob jects Classes in C are sp ecial cases of typ es classes sp ecify
prop erties of rst class ob jects while typ es sp ecify prop erties of non rst class ob jects C inher
itance rules are novariant however C allows p olymorphic function and metho d sp eci cations by
using a metho d function signature instead of a name for identi cation purp oses In the presence
of static typ e checking this is equivalent to a restricted form of static multiple dispatch Non rst
class ob jects in C are op erated up on by free functions only ob jects instances of classes have
metho ds C also provides parametric typ es templates that can take an arbitrary number of
parameters parametric typ es can b e subtyp ed
The C typ e system is not veri able in general due mostly to its unrestricted use of p ointer
conversions however partial veri cation is p ossible and is p erformed at compilation time The C
typ e system combines interface and implementation inheritance and thus violates the rst inheritance
requirement It is not completely uniform as it distinguishes b etween data and ob jects and treats
Table Typ e system expressibility
Subtyping Metho d Dispatch Parametric typ es Mutable Intersection
Typ e system Inheritance typ es Bounded Intra Inter typ es typ es
C User defined Multiple Single
E User defined Multiple Single
O User defined Multiple Single n a n a n a
O User defined Single n a n a n a
Java User defined Multiple Single n a n a n a
GJ User defined Multiple Single
JPE User defined Multiple Single
Pizza User defined Multiple Single
JVT User defined Multiple Single
ODMG User defined Multiple Single n a
DBPL User defined n a n a n a n a n a
Mo dula User defined Single Single n a n a n a
Mo dula User defined Single Single n a n a
Ob eron Structural n a Single n a n a n a
Theta User defined Multiple Single
Ada User defined Single Single
Sather User defined Multiple Single
Emerald Structural n a Single n a n a Unknown
BETA Structural Single Single n a n a
Napier n a n a n a n a
Strongtalk Structural Single Single
Cecil User defined Multiple Multiple
BeCecil User defined Multiple Multiple n a n a n a
Mini Cecil User defined Multiple Multiple
Transframe User defined Multiple Multiple
TM Both Multiple Single
ML Structural n a n a n a
Machiavelli Structural n a n a n a n a n a
Fib onacci User defined Single Unknown n a n a n a Implicit
ML Both Multiple Multiple Implicit
PolyTOIL Structural n a Single n a n a
Lo op Structural n a Single n a n a n a Implicit
TL Structural n a n a
TooL Structural Multiple Single
TOFL User defined Multiple Multiple Implicit
Structural subtyping is the default however user can explicitly turn it off when needed
User defined for classes structural for algebraic data types
Only for interfaces classes have single inheritance
Blo cktyp es only
Only virtual functions are dispatched
Only tagged types are dispatched
Dispatch mo deled as record field extension execution
Only system defined parameters can only b e used for sp ecification of prop erties
These features are based on modules rather than on types
The language provides mechanism more expressive then b ounded quantification
Always covariant
Only covariant and novariant parameters are allowed
Table Typ e system tests
Typ e system PERSON POINT COMPARABLE STREAMS SORT GENSORT LIST SET APPLY BROWSER
C
E
O
O
Java
GJ union
JPE union
Pizza union
JVT
ODMG union
DBPL
Mo dula
Mo dula
Ob eron
Theta
Ada
Sather
Emerald
BETA
Napier
Strongtalk union
Cecil
BeCecil
Mini Cecil
Transframe union
TM
ML
Machiavelli
Fib onacci
ML union
PolyTOIL
Lo op
TooL
TOFL union
Relies on dynamic typ e checking
Only suggestivetyp e checking
While the subtyping relationship required by the test holds one typ e can not b e derived from the other
If typ e parameters are explicitly instantiated
This test can b e only programmed with blo cks rather than messages
Built in op erators for dealing with sets are provided however their typing is sp ecial non user definable
If RTTI is present
Even though a typ e can b e examined dynamically typ echecking do es not takethisinto account
attributes in a sp ecial way C provides a limited substitutability for ob ject p ointers not for
ob jects In terms of expressibility the C typ e system is quite p owerful as it has function typ es
parametric typ es orthogonal typ e constructors and deals with mutable ob ject typ es However
when used on the test suite the C typ e system fails all tests except for GENSORT Other
tests can b e programmed but only with signi canttyp e checking lapses The reason for this is
the fact that C do es not handle the typing of binary metho ds since it lacks multiple dispatch
Parametric typ es in C can only b e used when fully instantiated thus limiting a programmer s
ability to de ne p olymorphic functions metho ds Typ e parameters are always unrestricted and
novariant The variant of C that includes run time typ e information RTTI allows for dynamic
typ e checking allowing it to tentativelypasstheBROWSER test Intersection and union typ es
can not b e represented by the C typ e system The C typ e system is also quite complicated
E RCS is derived from C and b orrows much of the typ e and class system from it Dif
ferences b etween E and C lie in the sp eci cation of parametric typ es and in the fact that E is
a p ersistent language In E as opp osed to C parametric typ es called generic classes can b e
sp eci ed using a general typ e parameter restriction mechanism however subtyping for parametric
classes can not b e de ned in E This mechanism allows a programmer to sp ecify restrictions on
metho ds of a parameter typ e For example it is p ossible to require a certain function metho d
parameter typ e to haveacompare metho d with a given sp eci cation thus making the test SORT
succeed As a p ersistent language E is not completely uniform as its p ersistence is typ e dep endent
E also fails the BROWSER test
O AG is another p ersistent language derived from C It is similar to C in all
resp ects except for provisions for p ersistence queries and a limited form of typ e re ection Persis
tence in O is not typ e based thus its typ e system is uniform in this resp ect Typ e re ection
in O is provided by the means of the is op erator that checks whether a given ob ject has a given
O still do es not have orthogonal p ersistence as its p ersistence is declaration based also p ersistent ob ject
creation is di erent from transient ob ject creation
typ e However the BROWSER test in O still fails with resp ect to typ e checking even though it
can p otentially b e programmed The SETS test also fails as O queries do not provide the full
power of SQL even though the typing for forall and suchthat is present in O at the op erator
non user de nable level
O LRV provides a family of languages but its typ e system is the same in all of them so
here the discussion is based up on the CO language which is based on C The typ e system of
O makes a distinction b etween rst class and non rst class ob jects called values in O however
values in O are mutable O uses the term type to refer to implementation typ es of non rst
class ob jects and the term class to refer to typ es of rst class ob jects which combine prop erties of
interface and implementation typ es Thus the typ e system of O is not completely uniform in that
only rst class ob jects are manipulated by metho ds much like in C Inheritance in O is based
on implementation subtyping with an additional ability to add or mo dify metho ds O adopts a
covariant signature re nement rule thus providing for more natural data mo deling However in the
absence of multiple dispatch this covariant rule results in the loss of static typ e safety and thus the
typ e system of O is unsound O do es not provide any kind of parametricity metho ds messages
and typ es are not ob jects in O O is uniform in terms of p ersistence it is orthogonal to the typ e
O also makes provisions for dynamic schema evolution however this evolution is not typ e safe
O s typ e system essentially fails all tests for typ e system expressiveness since even the tests that
could b e programmed would pass typ e checking and fail at run time In BC multimetho ds are
used to provide typ e safety for covariant sp eci cations in the O programming language With the
addition of the mechanisms describ ed in the article test POINT would succeed while the others
would still fail
Java AG has recently b ecome a p opular language in b oth academic and industrial commu
nities Its typ e system shares many features with that of C therefore the discussion will fo cus
primarily on its di erences from the latter The advantages of the Javatyp e system include sep
aration b etween interface and implementation b etter handling of run time typ e information and
simpli cation of the overall typ e system design resulting in a much more transparenttyp e system
A non re exiveJava fragment has b een shown to b e typ e safe DE while the full language has
certain typ e de ciencies Sar On the other hand the Javatyp e system lacks metho d typ es all
metho ds when considered as ob jects have the same typ e in Java parametric typ es except for
statically unsafe parametric arrays which are built in and inherits some of the problematic fea
tures of the C typ e system discussed ab ove Java fails all tests except for SORT the latter b eing
successful due to the presence of interfaces Java fails the GENSORT test as its metho d typ es are
not su ciently expressive for this test
Recently several parametric extensions to the Javatyp e system have b een prop osed Generic
Java GJ BOSW c BOSW a BOSW b adds parametric typ es to the static typ e system
while using the same run time mo del typ e parameters are erased and do not exist at run time
Parametric typ es in GJ are novariant and parameters can only b e of reference class typ es There
are also several restrictions on the usage of parametric typ es and metho ds related to the particular
typ e inferencing algorithm used in GJ GJ passes the test COMPARABLE and the union part of
the SET test in addition to the SORT test passed byJava
Another parametric typ e extension of Java is prop osed in MBL JPE It allows usage of non
reference typ es as typ e parameters and also uses where clauses to express requirements on parameter
typ es In this extension parametric typ es are also novariant The typ e checking algorithm is not
presented in MBL This extension has test suite p erformance identical to that of Generic Java
but provides a more uniform system These two approaches are informal in that they do not have
a theoretical pro of of their soundness
Yet another Java extension is Pizza OW which extends Java with parametric and function
typ es The approachtaken in OW is similar to that of MBL but is much b etter formalized
In fact Pizza would have b een statically typ e safe if not for covariant arrays whichwere left in Pizza
for Java compatibility It is shown that the resulting typ e system do es not have the subsumption
prop erty However the same is true of all Java extensions considered so far as well as of Java itself
Pizza passes tests GENSORT and APPLY in addition to COMPARABLE and SORT due to the
presence of metho d typ es A similar set of extensions is prop osed in AFM but without metho d
typ es and a supp orting theory The latter approach however do es lift several restrictions placed on
the usage of typ e parameters in Pizza
A di erentapproach is taken by Thorup Tho where Java is extended with virtual types
JVT Here the choice is made in favor of convenience and b oth static typing and dynamic
substitutability are sacri ced Because of this tests PERSON COMPARABLE and LIST could
b e programmed but would give run time rather than compile time errors in incorrect cases A
mo di cation of this approach is presented in BOW which also compares parametric and virtual
typ e approaches
BC extends Javawithmulti metho ds that are intro duced via the so called parasitic methods
The goal of this extension is to add supp ort for multi metho ds to the existing language providing
full compatibilitywithJava BC contains pro of of soundness for the resulting system
The Ob ject Database Management Group has develop ed a set of standards for ob ject database
management systems CBB Two of these standards sp ecify an ob ject mo del ODMG Ob ject
Mo del and an ob ject query language OQL The ob ject mo del includes typ es that sp ecify abstract
prop erties and abstract b ehavior of their ob jects Typ es are categorized as interfaces abstract
b ehavior only classes and literals abstract state only Typ es are implemented by language
sp eci c representations a single typ e can have several representations but only one of them can b e
used in a single program Interfaces supp ort multiple inheritance while classes only supp ort single
inheritance class extension Thus ODMG Ob ject Mo del provides separation b etween interface and
implementation Interfaces in this mo del can not b e instantiated Abstract prop erties in ODMG
Ob ject Mo del include abstract state and abstract relationships two way mappings Relationships
can only b e de ned b etween classes Abstract b ehavior is sp eci ed as a set of operations Behavior
sp eci cations are novariant in b oth their argument and return typ es ODMG Ob ject Mo del supp orts
single dispatch Several system de ned parametric container classes are present in the ob ject mo del
but the user is not allowed to de ne new ones Typ e parameters can only b e used in prop erty
sp eci cations op eration sp eci cations can not b e parameterized OQL is a strongly typ ed query
language that provides a p ossibility of explicit dynamically checked typ e conversions Set op erations
in OQL can only b e p erformed on compatible typ es typ es that have the least upp er b ound
Since the notion of the greatest lower b ound is not available in OQL all set op erations use the
least upp er b ound for typing purp oses For example intersecting a set of students with a set of
p ersons would return a result of typ e set of p ersons even in the case when the typ e of students is
a subtyp e of the p erson typ e ODMG OQL fails all tests except for BROWSER and the union part
of the SET test It should b e noted however that ODMG OQL is not a general purp ose database
programming language and therefore its p erformance on the test suite is not fully indicative of the
merits of the ODMG Ob ject Mo del
The following group of languages is based directly or indirectly on Mo dula Wir Mo dula
is neither ob ject oriented nor a p ersistent language Its typ e checking is veri able Mo dula has a
construct for separating interface and implementation in the form of interface and implementation
modules and the languages based on Mo dula also use this approach This mechanism has proven
to b e very convenient and robust for pro cedural languages However its advantages and disadvan
tages for ob ject oriented languages with their primarily typ e based approachtobothinterface and
implementation sp eci cation are yet to b e evaluated
DBPL SM is one of the p ersistent languages based on Mo dula In DBPL mo dularity
is achieved by using the native language Mo dula mo dularization mechanisms with a sp ecial
DATABASE MODULE construct In the absence of mo dule p ersistence it do es not cause problems
with orthogonality Transactions are supp orted as sp ecial pro cedures Partial SQL compatibility
is provided by the use of a RELATION OF typ e constructor with the appropriate set of op erations
and rst order constructs ALL IN SOME IN andFOR EACH DBPL also allows up datable and non
up datable views via SELECTOR and CONSTRUCTOR pro cedural sp eci cations DBPL is not ob ject
oriented however it do es o er implementation typ es with no metho ds The DBPL typ e system is
static and non re exive The tests describ ed in Section are not applicable to DBPL directly as
it is not ob ject oriented DBPL would tentatively pass only the test GENSORT The DBPL typ e
system is uniform in that system and user de ned typ es have the same rights
Another p ersistent language based on Mo dula is Mo dula LML Mo dula has some
rudimentary ob ject oriented capabilities single inheritance and is similar to C in that metho d
signatures are novariant ob ject typ es are di erent from other typ es implementation and interface
hierarchies coincide and there is only a limited supp ort for function typ es Thus the Mo dula typ e
system is not uniform An interesting prop erty of Mo dula is the presence of typ e DYNAMIC Data
of this typ e are pairs of values and their typ es expressed as values of a comp ound typ e DATATYPE
Typ e DATATYPE is the typ e of the representations of all data typ es in the system it can b e used
indep endently of DYNAMIC typ e to store retrieve and op erate up on various data typ es Anyvalue
can b e co erced to the typ e DYNAMIC Mo dula provides a sp ecial op erator TYPECASE that provides a
typ e safe interface to the valuesoftyp e DYNAMIC The language also provides a set of prede ned typ e
op erators that can b e used to op erate on valuesoftyp e DATATYPE Thus Mo dula provides typ e
safe immutabletyp e re ection The Mo dula typ e system is static and non parametric however
it do es provide orthogonal p ersistence The only expressibility tests that would succeed in Mo dula
are GENSORT and BROWSER Mo dula provides incremental typ e checking including its
dynamic variety
Mo dula Har is another language with ob ject oriented extensions based on Mo dula
Mo dula is not a p ersistent programming language and its ob ject extensions are similar to those of
Mo dula it also has TYPECASE statement that gives a programmer the ability to request dynamic
typ e checking in a typ e safe manner Mo dula has parameterized modules however parameter
ized types are not allowed Mo dula passes the tests COMPARABLE SORT GENSORT and
BROWSER
Another descendant of Mo dula is Ob eron MW Subtyping in Ob eron is based on record
extension also known as structural subtyping The subtyping relationship is prede ned for atomic
typ es Thus Ob eron has multiple subtyping Ob eron supp orts single dispatch Subtyping of
pro cedure metho d typ es is based on novariance of argument and result typ es only the receiver
typ e is covariant Parametricity is not supp orted by Ob eron Separation b etween interface and
implementation is supp orted at the level of modules in the same manner as in all Mo dula based
languages Ob eron also has an extended WITH statementthatallows a programmer to dynamically
insp ect the typ e of an ob ject and act according to it This statement is similar to the TYPECASE
statement in Mo dula and Mo dula discussed earlier The typ e system of Ob eron would pass
the tests SORT GENSORT andBROWSER
There has b een a prop osal for adding parametric typ es and metho ds to Ob eron RS In
this prop osal parametric typ es are novariant and the typ e checker ensures that a parameter typ e
substitution exists that satis es the rules for matching arguments of a particular call Unfortunately
neither the typ echecking algorithm nor the pro of of its soundness are present in RS
Lago ona Fra is another descendant of Ob eron It fo cuses on messages objects and message
passing In contrast to most ob ject oriented languages a message in Lago ona is an indep endent
entity Aninterface category in Lago ona is a set of messages Each message has a typ e sp eci
cation There can b e several methods implementing a message each for a di erent receiver typ e
Implementation in Lago ona is sp eci ed byaclass usually a record typ e when a category meets a
class atype combination of interface and implementation is b orn No co de inheritance is p ossible
in Lago ona only structure inheritance is p ossible Variables in Lago ona can b e sp eci ed using either
category or class Lago ona thus provides a complete separation b etween interface implementation
representation and co de metho ds When a message is sent to an ob ject an ob ject can forward
resend it to another ob ject Other features of the Lago ona typ e system include single dispatch
and single inheritance Unfortunately the article Fra provides insu cient information to test
the p erformance of Lago ona on the test suite
The language Theta DGLM combines the expressivepower of parametric and inclusion p oly
morphisms It also provides where clauses that give its typ e system a exibility similar to that
provided by matching Theta has single dispatch multiple inheritance for typ es interfaces and
single inheritance for classes implementations Theta only allows novariant parametric typ es
Metho d typ es can b e sp eci ed in Theta and metho ds functions can b e used as rst class values
Theta also has re exive capabilities in the form of the typecase op erator Theta s typ e system is
veri able uniform and static It is also quite expressive However the its soundness has not b een
proven Theta passes the tests COMPARABLE SORT GENSORT LIST and BROWSER
The language Ada Ada is a pro cedural language with some ob ject oriented features Ada
has a remarkably strong supp ort for parametricity generic packages parametric mo dules and
generic subprograms parametric functions can not only b e instantiated but also used as parameters
of other generic entities thus providing for great exibility Parameter typ es can b e constrained by
a with clause requiring the typ e to have a metho d with a particular signature which can also b e
parameterized However Ada generics have to b e fully and explicitly instantiated b efore they can
b e used Another interesting and p owerful feature of Ada is the notion of an access type which
generalizes such notions as p ointer and reference allowing also for user de ned access typ es
Ada also has function typ es and function arguments can b e sp eci ed as in out orinout according
to the role they play Ada uses its package mechanism similar to the mo dule mechanism of Mo dula
to provide separation b etween interface and implementation On the other hand ob ject oriented
Ada features app ear to b e relatively weak in order to b e used for dynamic dispatch a typ e has
to b e explicitly declared as tagged In order to b e able to use subtyping inclusion p olymorphism
a programmer has to use a sp ecial form of parameter sp eci cation Ada provides single dispatchand
single inheritance with novariant metho ds Sub classing in Ada is limited to record extension In
Ada typ es can b e examined dynamically data of a typ e can b e converted to any other typ e and such
aconversion is dynamically typ e checked The Ada typ e system is very complicated and it places
emphasis on static rather than dynamic p olymorphism Ada will pass the tests COMPARABLE
SORT GENSORT LIST and BROWSER provided generic packages rather than typ es are used
Next the object oriented language Sather SO will b e considered Sather is based on the much
b etter known Ei el Mey however Ei el is not discussed here as one of the primary goals b ehind
the design of Sather was to remedy typing problems present in Ei el
Sather has multiple interface and implementation inheritance hierarchies almost indep endentof
each other concrete implementation typ es called classes in Sather must have leaf interface typ es
Implementation subtyping in Sather corresp onds to textual inclusion with replacements Sather
uses single dispatch and is strongly and statically typ ed Therefore its metho ds are covariant on the
receiver and contravariant on other arguments Sather also provides partial closures of its metho ds
and iterators as rst class values It has parametric implementation typ es that can use a form of
b ounded p olymorphism to constrain typ e parameters These parametric typ es are novariantand
they can not b e used until fully instantiated Metho d arguments in Sather can b e sp eci ed as
in out or inout according to the role they play The Sather typ e system correctly handles all
these cases Argumenttyp es and lo cal variables can b e sp eci ed by using either Sather typ es or
Sather classes In the former case the parameter class has to b e a subtyp e of the given typ e in the
latter case the parameter class has to match the sp eci cation exactly The language also provides a
novel notion of iters iterators that are an ob ject oriented generalization of lo op control structures
Sather also provides a sp ecial comp ound typ e TYPE and op erators typeof and typecase Thus it
has typ e safe immutable typ e re ection The typ e system of Sather therefore p ossesses veri ability
even though it has not b een formally proven and satis es inheritance and partially uniformityand
expressibility requirements It passes tests PERSON COMPARABLE SORT GENSORT LIST
and BROWSER and fails on tests POINT STREAMS SET andAPPLY Note that APPLY fails
b ecause parametric typ es in Sather require full instantiation b efore they can b e used
Emerald RTL is a non traditional ob ject oriented language that combines features of class
based and delegation based ob ject oriented languages Ob jects are created in Emerald by a sp ecial
syntactic form called an object constructor The ob ject constructor plays a triple role rst it
de nes the ob ject s implementation second it de nes a publicly visible ob ject interface type in
Emerald third it denotes the pro cess of ob ject creation itself Subtyping in Emerald is structural
as a typ e is understo o d as a set of signatures Typ es are also ob jects that can b e created byobject
constructors thus a user can de ne new typ es including parametric ones The typ e checker uses
user de ned typ es along with system supplied ones to typ echeck a program statically Since typ es
are ob jects dynamic typ e checking is also p ossible The Emerald typ e system is therefore veri able
uniform re exive satis es inheritance requirements and is quite expressive However its soundness
is unknown Emerald passes the tests PERSON STREAMS SORT andBROWSER
BETA MMPN is a unique ob ject oriented language that uni es the notions of class ob ject
and pro cedure metho d via its notion of a pattern Patterns can contain other patterns suchas
memb er ob jects co de fragments and typ es BETA also has fragments that play the role of mo dules
and can also b e used to separate interface from implementation BETA fragments can b e regarded
as high level restricted patterns since they op erate on the same basic principles Patterns can b e
virtual a virtual pattern can b e extended by adding co de fragments in places sp eci ed by the inner
placeholder a k a metho d extension as in Simula BDMN by extending a virtual pattern
with additional memb ers a k a record extension or by supplying a class pattern in place of a
virtual one a k a parametric instantiation Virtual patterns have to b e explicitly declared as
such Uni cation of all language concepts using the notion of pattern makes it p ossible to design a
very p owerful language based on only a couple of orthogonal principles While the language design
simplicityisvery impressive the resulting language is quite unconventional Structural subtyping in
conjunction with a class substitution mechanism makes the typ e system of BETA statically unsound
dynamic typ e checks are inserted to ensure typ e safety Due to the uniformityofBETA all tests
except for POINT can b e co ded in it but only SORT and GENSORT have static typ e safety Illegal
usage in other tests would cause run time typ e errors
In the p ersistent ob ject oriented language VML KT all ob jects that are instances of ob ject
typ es called classes are p ersistent while all non rst class ob jects of non ob ject typ es called data
types are transient However a value of a non ob ject typ e can b ecome p ersistent if it is referenced
from a p ersistent ob ject Thus VML do es not have orthogonal p ersistence VML ob ject typ es are
rst class ob jects and as such b elong to their resp ective metaclasses Metaclasses de ne some of the
essential class metho ds for example the metho ds for the inheritanceBehavior message that is used
when a metho d for a message is not found in the receiver class Thus VML allows user de ned
metho d inheritance due to its classes are ob jects concept However VML data typ es are not rst
class ob jects and thus VML only partially satis es the typ e re exivity requirement Inheritance in
VML can b e tailored to sp eci c application needs by using the user de nable inheritanceBehavior
message found in an appropriate metaclass VML do es not haveaveri able typ e system therefore
the tests are not applicable to it
The p ersistent programming language Napier version MBC is not an ob ject oriented
programming language however its typ e system is quite p owerful In Napier parametric typ es
can b e built freely from the basic typ es typ e constructors and typ e variables Parametric pro cedures
pro cedures with parametric typ es can also b e de ned and are rst class ob jects Napier typ es
are purely implementation typ es however Napier provides the typ e constructor abstract that
may b e considered as an interface typ e as it provides existential quanti cation over witness typ e s
Thus the typ e system of Napier satis es all expressibility requirements not related to the notions
of subtyping and inheritance However since Napier do es not have the notions of subtyping and
inheritance it fails the requirements related to those notions In Napier parametric typ es can not
b e used until fully instantiated Napier provides supp ort for a limited form of linguistic re ection
via dynamic environments Environments are dynamically typ ed structures that provide bindings
of names to Napier entities Environments can b e dynamically mo di ed insp ected and used in
expressions Environments can b e p ersistent
Napier has a sp ecial typ e any that is a union typ e of all typ es in the system A sp ecial project
op erator can b e used to deal with values of typ e any in a typ e safe manner This op erator is similar
to TYPECASE of Mo dula Since anyvalue can b e injected into typ e any the ab ove mechanism
makes run time data typ e insp ection p ossible Thus the typ e system of Napier has typ e safe typ e
re exive capabilities
The p ersistent store of Napier is an ob ject of typ e any that holds a typ ed collection of ob jects
The ob jects from the p ersistent store can b e pro jected from any and op erated up on transparently
after that Napier uses a p ersistence mo del based on reachability from the ro ot p ersistent store
ob ject Thus the p ersistence in Napier is orthogonal to typ e
In spite of the p ower of its typ e system Napier would only unconditionally pass the test LIST
It would however tentatively pass the tests COMPARABLE SORT GENSORT andAPPLY if
usage of explicit typ e parameters in parametric calls were allowed In other words the burden of
inferring correct parametric instantiation from the co de in Napier is placed on a programmer
rather than on the typ e checker
Next purely ob ject oriented programming languages typ e systems will b e reviewed The rst
language to b e considered in this group is Strongtalk BG which is a statically typ ed version of
Smalltalk GR Smalltalk is widely regarded as the rst purely ob ject oriented language however
it has no static typ e checking
In Strongtalk everything including typ es called classes in Strongtalk metho ds and messages is
a rst class ob ject Thus Strongtalk is uniform All Strongtalk ob jects can b e op erated up on and
mo di ed at run time and therefore Strongtalk is re exive the re exivityistyp e unsafe Strongtalk
separates interfaces protocols from implementations classes provides subtyping and matching It
also has parametric novariant typ es and messages blo cktyp es and union typ es However the user
has to explicitly sp ecify a mechanism to guide parametric typ e inferencing resulting in the loss of
substitutability It is also unclear from BG whether Strongtalk allows b ounded parametric typ es
Strongtalk provides single inheritance and single dispatch Subtyping is structural but the user can
use brands to restrict it Even though Strongtalk was not designed to b e a p ersistent language it do es
provide uniform p ersistence of its ob jects in a so called image Overall the Strongtalk typ e system
is quite expressive uniform and re ective It passes the tests COMPARABLE LIST BROWSER
and p ossibly GENSORT if parametric typ e b ounds are allowed The union part of the SET test
is also passed Strongtalk would fail the tests PERSON POINT STREAMS aswell as APPLY
and SORT the latter two could b e programmed but only with blo cks rather than messages
Cecil Cha Cha b is a delegation based language that has b oth implementation and interface
typ es the former are called representations while the latter are called types Typ es in Cecil are used
for suggestivetyp e checking only as Cecil s multiple dispatch is done according to representations
Cecil s typ e checking is suggestive b ecause it might rep ort false errors or miss real ones therefore
its typ e discipline is not enforceable Cecil s do es not supp ort incremental typ e checking Cecil
uses multiple dispatch and provides covariant sp eci cation of sp ecialized arguments together with
contravariant sp eci cation of unsp ecialized ones Closures and metho ds are rst class ob jects in
Cecil they are contravariantly typ ed Cecil also provides novariant parametric typ es and metho ds
as wellastyp e parameter b ounds Parametric typ es in Cecil can b e instantiated either explicitly or
implicitly in the latter case the user has to provide a hinttothetyp e inferencing algorithm This
b ehavior results in loss of substitutability Cecil has multiple inheritance union and intersection
typ es Overall the Cecil typ e system is quite expressive and uniform while b eing non re exive and
static It also satis es the inheritance requirements Since Cecil typ e checking is only suggestive
it is di cult to apply the tests to it However tests that Cecil would tentatively pass include
PERSON POINT SORT GENSORT LIST SET APPLY and BROWSER Itwould fail the tests
COMPARABLE due to the restrictions on parametric typ e b ounds and STREAMS due to the
novariance of parametric typ es
There are several extensions mo di cations to the original Cecil language One of these extensions
is BeCecil CL CL BeCecil is a statically typ echecked version of Cecil It supp orts blo ckand
mo dular structure has extensible ob jects and an extensible typ e system and its typ e system has
b een formalized However soundness and substitutability prop erties haveyet to b e proven BeCecil
also has a novel notion of acceptors which can b e considered as an ob ject oriented generalization of
the assignment op erator However BeCecil do es not have parametric typ es while sharing most of the
other features with Cecil The absence of parametricity contributes to the decreased expressibilityof
the BeCecil typ e system as compared to that of Cecil BeCecil passes the tests PERSON POINT
SORT GENSORT andLIST and fails the rest
Another mo di cation Mini Cecil is describ ed in Lit Mini Cecil strives to achieveacom
bination of static typing and a very general form of parametric p olymorphism Mini Cecil also has
frameworks which are basically interfaces with what app ears to b e an analog of selftype The
frameworks can b e used to separate interface and implementation as well as to achieve the e ect of
matching Metho ds in Mini Cecil are rst class ob jects multimetho ds and multiple inheritance are
supp orted Subtyp e clauses can have a form of forall C isa C C isa C where is a
set of free typ e variables and C are typ e sp eci cations The resulting typ e system is very expressive
i
Except for a p ossible uniformity breach in the form of direct attribute access
Being a delegation based language Cecil has language re ection however the typ e system of Cecil is not re exive
as Cecil typ es are not ob jects and can not b e manipulatedby the language More precisely representations of Cecil
are re exivewhile types are not
it can even b e argued that it is the most expressivetyp e system p ossible However the typ echecking
seems to b e undecidable The algorithm prop osed is a conservative approximation and its soundness
is yet to b e proven It is also unknown if the resulting typ e system has substitutability Mini Cecil
would pass all tests except for BROWSER as it do es not have re exive capabilities
Transframe Sha allows the user to sp ecify whether a parameter of a parametric typeisto
be covariantornovariant type exact and to constrain it by giving it an upp er b ound Subtyping
and sub classing interface and implementation inheritance are di erent concepts in Transframe
There is a distinct name selfclass that allows classes to supp ort matching The language uni es
the notions of class and function likeBETA Transframe also supp orts multiple dispatch There
are provisions for dynamic typ e checking and dynamic schema evolution Transframe implicitly
instantiates parameter typ es in expressions unfortunately there is no formal pro of of typ e safety
In fact it can b e shown that the typ e system presented in Sha isnot typ e safe Overall the
Transframe typ e system is veri able very expressive almost uniform and dynamically re ective
However it is unsound Transframe would pass all expressibility tests except for the test STREAMS
due to its inability to representcontravarianttyp e parameters and the intersection part of the test
SET due to the absence of intersection typ es
CLOS Common LISP Ob ject System BDG is a re exive language with all the p ower
of Common LISP re ection CLOS has typ es and ob ject typ es called classes the latter b eing
a subset of the former CLOS typ es are implementation typ es they do not sp ecify anyinterface
However CLOS classes combine implementationandinterface de nitions Since CLOS makes a
distinction b etween ob ject and non ob ject typ es where only ob ject typ es de ne interfaces and are
sub ject to inheritance the CLOS typ e system is not completely uniform CLOS classes are ob jects
that b elong to metaclasses which are also ob jects CLOS messages metho ds and functions are also
CLOS ob jects that can b e op erated up on and changed at run time so CLOS is fully re exiveand
dynamic Sub classing in CLOS is slot collection extension with slot typ es changed covariantly a
typ e of a slot is the intersection of the typ es sp eci ed for this slot in all of the class sup erclasses
Messages called generic functions are also covariant CLOS is not statically typ ed ACLOS
message can b e dispatched to yield an appropriate metho d or a combination of metho ds according
to the class or value of all arguments multiple dispatch Metho ds are covariant on all arguments
since CLOS has multiple dispatch If more than one metho d is appropriate for the given arguments
a user de nable way of constructing the function to b e executed out of al l appropriate metho ds is
employed In the b o dy of a metho d a sp ecial function call next method can b e called to invoke the
next applicable metho d This capability is analogous to the inner construct of Simula BDMN
and is much more p owerful Overall the dispatchmechanism of CLOS is the most p owerful of all
known mechanisms if the consideration is limited to classes and values CLOS can not dispatchon
typ es Up dates in CLOS are invoked on slots directly or by using an appropriate message CLOS is
not statically typ e checked therefore a run time error is signalled if a value assigned to a slot do es
not conform to the slot s typ e sp eci cation Since CLOS is not statically typ ed the tests are in
general not applicable to it however CLOS would pass POINT APPLY andBROWSER tests if
its typ e discipline were enforceable
Dylan App is an imp erative programming language similar to CLOS While there are certain
di erences b etween the two they are almost identical in terms of their typ e systems Dylan has
more control over the de ned classes as Dylan classes can b e sealed only sub classable by the library
where they b elong or op en primary there is only single inheritance of primary classes or free
abstract all sup erclasses of an abstract class must b e abstract or concrete There is also supp ort
for singleton typ es but not singleton classes Multiple dispatch in Dylan is also di erent from that
in CLOS in that in Dylan all arguments are equal and the metho d sp eci city is de ned by a class
precedence list Dylan also has mo dules with imp ort and exp ort lists and mo dule libraries
TM BBdB is an ob ject oriented p ersistent language with many functional features TM has
averi able typ e system based on Car However the soundness pro of seems to b e missing TM s
typ e hierarchy includes user de nable sorts atomic immutable typ es and classes Sorts and classes
have representation implementation typ es that are almost hidden inside of them Metho ds and
More precisely metho ds are covariant on those arguments that are constrained by class sp eci cations
typ es are not rst class values in TM TM metho d sp eci cation uses selftype to achieve the e ect
of matching Since this is the only p olymorphic mechanism in TM sp eci cations are covariantand
substitutability do es not hold as functional up dates are present No metho d rede nition mechanisms
are provided in TM The TM typ e system extends the typ e system of Cardelli Car withapowerset
typ e constructor Since TM is stateless p owerset typ es are covariant TM allows enumerated as
well as predicative sets as primitive language expressions Enumerated sets in TM can only b e
homogeneous while predicative sets can b e heterogeneous up to subtyping Predicativesetsin
the presence of the record based typ e system of Car and the absence of up dates play a role of
emb edded queries that are highly integrated with the rest of the language TM provides several levels
of constraint sp eci cation mechanisms which are also set based and resemble relational constraint
systems TM also provides rst order set op erations However the set op erations require sp ecial
treatment and are not messages in the usual ob ject oriented sense It is also unclear howwell di erent
typ e constraints for di erent kinds of sets interact with each other TM has mo dules that de ne their
p ersistent comp onents by names and everything those ob jects refer to is also implicitly p ersistent
Thus TM provides a combination of static name based and dynamic reachability based p ersistence
completely orthogonal to the typ e Overall the TM typ e system is veri able sound supp orts
b oth interface and implementation inheritance though they are not completely indep endentof
each other is almost uniform partially expressive and provides supp ort for declarative queries
However it do es not supp ort substitutability and is non re exive and static It would unconditionally
pass tests SORT and LIST Test SET also succeeds b ecause of built in supp ort for set op erations
However it would not b e p ossible to construct user de ned typ es with the same functionality
Most of the following languages b orrowmuch of their expressiveness from ML MTH ML is
a language with b oth functional and imp erative avors it also has some ob ject oriented features
This can b e said ab out almost all the languages discussed b elow
Standard ML MTH is a functional language with some imp erative features It is strongly
typ ed and provides provably decidable and sound typ e checking In the ML typ e system all typ e
information is inferred by the typ e checker Addition of explicit typ e annotations and declarations
is considered in OL Standard ML also providesavery sophisticated mo dule system where
eachmodule structure has its typ e signature However ML s structures are more like abstract
implementation typ es than mo dules as they are designed to shield their internals from the rest of
the program and not to handle separate compilation or similar tasks There is no notion of subtyping
in Standard ML except for signature matching which can b e considered as restricted structural
subtyping for abstract interface typ es Highly parametric typ es are supp orted in Standard ML
They can arbitrarily include typ e variables and can b e user de ned Thus the typ e system of
Standard ML is uniform For interface typ es signatures there are also functions that map signatures
to signatures functors Function typ es in ML can also b e p olymorphic Polymorphism in Standard
ML function typ es is expressed via typ e expressions that have to b e pattern matched For example
the typ e of the identity function in Standard ML is a a where a is a typ e variable This kind
of p olymorphism is uniform in that it allows user de ned parametric typ es Standard ML b eing in
essence functional allows up dates on so called ref typ es These typ es are reference typ es somewhat
similar to p ointer typ es in C or C ref typ es have a restricted parametricity as an argument
of a ref typ e must always b e a monotyp e e g see discussion in Wri Typ es are not ob jects
in Standard ML even though they can b e op erated up on by functions similar to those that op erate
on ordinary values Overall the typ e system of Standard ML is theoretically sound very expressive
and uniform while lacking inheritance and b eing only partially re exive This typ e system would
tentatively pass tests PERSON andSORT GENSORT and APPLY for the test SORT use of
mo dules rather than typ es is required
Another language from this family is Machiavelli OBBT BO which is a p ersistent language
that extends ML by adding more p olymorphism as well as query and view supp ort Machiavelli has
averi able and provably sound typ e system It adds record inclusion p olymorphism to ML by
using typ e variables of the form a that corresp ond to an arbitrary record extension Thus
Machiavelli allows more p olymorphic typ es than ML Machiavelli is also able to automatically
Provided that the notion of subtyping is substituted by the notion of co de reuse
maintain more sophisticated even non covariant typ e constraints on description types It is
therefore p ossible for Machiavelli s typ e checker to statically infer an error in case a join of two sets
of records whose typ es do not have a greatest lower b ound is attempted Machiavelli s typ e system
treats description and other typ es di erently Thus it is not completely uniform In Machiavelli
a sp ecial set typ e constructor is intro duced and query op erations are de ned for ob jects of set
typ es Machiavelli extends the typ e system of ML to b e able to deal consistently with typ e inference
of generalized relational op erations Machiavelli also provides views similar to those in relational
databases Namely a Machiavelli view is de ned as a function that returns a pro jection of a given
set over some appropriate typ e Overall the typ e system of Machiavelli is veri able sound
very expressive re exive partially uniform partially dynamic and capable of supp orting views
However it lacks interface inheritance It passes the same tests as ML with the addition of the SET
test due to the sp ecial supp ort of sets by the language and the typ e system
Fib onacci AGO is a p ersistent ob ject oriented language that is a descendant of Galileo
ACO which is in turn based on ML It has some functional and imp erative features and p os
sesses a veri able provably sound typ e system it also has multiple inheritance and single dispatch
In Fib onacci object types are indep endent from each other in terms of subtyping however role types
form indep endent directed acyclic graph DAG subhierarchies for each object type For example an
ob ject of typ e PersonObject can play roles Person Employee Student and TeachingAssistant
that is b oth Employee and Student Fib onacci roles can b e dynamically created and Fib onacci
ob jects can dynamically acquire new roles Fib onacci typ es are not ob jects in the language Metho d
arguments in Fib onacci are contravariant while their results are covariant Fib onacci supp orts a dis
tinction b etween metho ds and functions metho ds are attached to role typ es and are not Fib onacci
ob jects while functions are indep endent and are rst class values Fib onacci also has non ob ject
and non role typ es such as basic typ es class typ es function typ es and asso ciation typ es These
typ es form a hierarchy indep endent ofthatofobjectandroletyp es Fib onacci de nes some built in
parametric typ es Class Sequence and Association However it is unclear from AGO if
the user can create new parametric typ es In Fib onacci ob jects of the same ob ject typ e can have
di erent implementations These implementations are de ned at the time of ob ject creation Thus
an implementation in Fib onacci is not a part of an ob ject or role typ e sp eci cation Up dates in
Fib onacci are allowed on sp ecial novariant Var typ es In Fib onacci the syntax of message sends
determines the strategy of the metho d lo okup There are two strategies upwardlookup that corre
sp onds to the standard lo okup pro cedure in the presence of multiple inheritance and double lookup
that rst tries to nd an appropriate metho d in the subroles of the role it has started from Fib onacci
o ers declarative query op erators on parametric Sequence typ es These are typ es of immutablese
quences that are sup ertyp es of their resp ectivemutable Class and Association typ es Thus the
query facilities of Fib onacci are also applicable to Fib onacci classes and asso ciations Fib onacci
has a reachability based orthogonal p ersistence mo del Everything accessible from the top level
environment automatically p ersists b etween sessions Thus Fib onacci p ersistence is orthogonal to
b oth interface and implementation typ es Overall the Fib onacci typ e system is veri able prov
ably sound provides di erent inheritance for interface and implementation typ es and has inclusion
p olymorphism substitutability It is also expressive almost uniform and is capable of supp orting
query typing However it is non re exive and static The typ e system of Fib onacci would pass the
same tests as that of Machiavelli
The language ML BM b BM a is an extension of ML with subtyping and higher order
p olymorphic multi metho ds It has typ e inference strong static typ e checking and substitutability
ML like typeconstructors provide parametric p olymorphism Typ e constructors in ML can b e
sp eci ed as covariant novariant or contravariant The formalism used is based on the systems of
typ e constraints In this theoretical language no separation b etween interface and implementation
is provided Handling of imp erative mutable typ es is b orrowed from ML and is quite restrictive
w r t p olymorphism Another restriction placed on ML s typ e system is the requirement that all
typ es that have a subtyping relationship should have the same numb er of arguments as well as the
same variance sp eci cation for them Thus this typ e system fails the test STREAMS as it requires
Description typ es are ML typ es that do not include outside of ref
It is unclear whether Machiavelli handles view up dates
asubtyping relationship to b e established b etween parametric typ es of di erentvariances Overall
the ML typ e system is expressive veri able sound and static It passes the tests PERSON
POINT SORT GENSORT APPLY and the union part of the SET test However the inability
of the system presented in BM b to deal with recursive constraints makes generalization of the
system to unrestricted subtyping of parametric typ es quite di cult
There are several other approaches to adding subtyping to ML but none of them deals with
multi metho ds Aiken and Wimmers AWL AW prop osed a system that nds a solution for
a system of subtyping constraints this system can deal with recursive constraints Pottier Pot
also prop osed a system in which recursive constraints are allowed instead of solving the constraints
his system proves their consistency likethatofML Seq also adds subtyping and user de ned
typ e constructors as well as constrained typ es to an ML style typ e system The resulting system
app ears to b e similar to that of ML but lacks its ability to deal with multi metho ds Complexity
results related to solving subtyping systems app ear in Reh
MW prop oses a typ e system for a core subset of the purely functional language Er
lang AVWW The typ e system is similar to the one prop osed by Aiken and Wimmers AWL
AW and uses constrained typ e entailment for typ e veri cation The main di erence is the absence
of function typ es general unions and intersections The system is provably sound and presumably
complete Addition of function typ es to the system makes it incomplete and the pro of of sound
ness in this case is absent MW includes decidable algorithms for typ e inferencing signature
veri cation and constraint simpli cation
Castagna Ghelli and Longo CGL prop osed a variantof calculus calculus dealing
sp eci cally with multi metho ds Several imp ortant results generalized sub ject reduction Church
Rosser etc are proven It is also shown how the calculus can b e used to mo del inheritance matching
and multiple dispatch
CO presents a typ e system where a full edged supp ort for mutable typ es is added to an
ML style typ e system The approachtaken by the authors separates mutable and immutable typ es
by creating a parallel language syntax In essence every functional language construct has its imp er
ative counterpart Interaction b etween mutable imp erative and immutable functional language
comp onents is restricted byasetoftyp e validity rules that restrict p olymorphism of data typ es
for the data passed b etween the two language comp onents The approach of CO app ears to b e
sound but soundness seems to b e achieved at the exp ense of language simplicityandtyp e system
transparency
Next theoretical programming languages and systems that are designed sp eci cally for ob ject
oriented programming will b e reviewed
PolyTOIL BSG BSG has a veri able and sound typ e system and single subtyping Poly
TOIL identi es subtyping with substitutability while providing a concept of matching subtyping
up to MyType The latter is intro duced to allow for covariant metho d sp eci cation Subtyping
in PolyTOIL is structural as is matching The language allows for b oth subtyping and matching
constraints Matching is used as a mechanism of sp ecifying constraints that are weaker than sub
stitutability and is therefore useful for up datable typ es In Bru it is suggested that subtyping
should b e dropp ed altogether as matching is more intuitive and more exible In BSG there
are distinct notions of object types and class types The former are interface typ es while the latter
are implementation typ es Namely ob ject typ es sp ecify signatures typ e information for metho ds
applicable to the ob jects of this ob ject typ e while class typ es sp ecify instance variables and co de
for metho ds applicable to ob jects that b elong to the class Classes are used to create new ob jects
They are pro duced by applying functions whose arguments are values used to initialize the pro duced
ob jects as well as the argumenttyp es for parametric classes to their arguments Classes can use
inheritance with rede nitions Parametric typ es in PolyTOIL are pattern functions of their param
eter typ es A notion of a function typ e is also presentinPolyTOIL However it is only used in
sp eci cations and during typ e checking and is inherently di erent from either class or ob ject typ e
Overall the typ e system of PolyTOIL is veri able sound expressive almost uniform and satis es
inheritance requirements However it is static and non re exive It passes tests COMPARABLE
SORT GENSORT LIST and APPLY and fails the rest The PERSON test fails b ecause while
record subtyping allows metho d typ e rede nition record extension do es not
Lo op ESTZ EST b EST a is a theoretical language similar to PolyTOIL There are no
explicit typ e annotations in Lo op and the typing is inferred automatically Lo op has a concept of
subclassing where one class inherits from several other classes Subtyping and sub classing in Lo op
are di erent concepts Lo op enjoys provably sound typ e checking and a state semantics given by
its translation to So op Function typ es are present in Lo op however in the absence of explicit
typ e annotations they are only used internally for typ e checking purp oses Lo op classes are mech
anisms for creating ob jects Sub classes do not necessarily corresp ond to subtyp es and class and
typ e inheritance hierarchies are di erent The typ e hierarchy in Lo op is implicit while the class
hierarchy is explicitly sp eci ed by the programmer Sub classing can b e multiple and b oth metho ds
and instance variables can b e added inherited or mo di ed Since Lo op is a theoretical language
it do es not haveany syntactic sugar for sub classing whichmakes Lo op inheritance rather di cult
to use Up dates in Lo op are allowed for instance variables only The semantics of these up dates is
given by their translation to So op Lo op do es not have parametric typ es Subtyping in a similar
system has b een shown to b e decidable in TS The typ e system of Lo op is veri able sound
partially expressive almost uniform partially re exive static and satis es the inheritance require
ments It passes the same tests as PolyTOIL The typ e checking mechanism uses constrained typ es
The system do es not attempt to nd a solution to the system of constraints it generates rather it
veri es that such a system is non contradictory The theory guarantees that in this case the system
has a solution and the program is considered to b e typ e correct
TL Tyco on Language MS MMS is based on the F system CMMS Car From
F it b orrows constrained b ounded parametric typ es and typ e op erators as well as p olymorphic
functions and partial typ e inference It is also uniform in its treatment of functions including
higher order ones and atomic values In addition to these features TL has mutable typ es mo dules
and typecase statement Even though TL is designed on the basis of a formal system F its
typ e system features have not b een mathematically proven Thus the questions of soundness and
decidability remain op en for the TL typ e system TL is an orthogonally p ersistent programming
language Since TL is not an ob ject oriented language the tests are not applicable to it
In the To oL language GM an attempt is made to combine the notions of subtyping matching
and b ounded universal quanti cation The resulting language is quite p owerful in terms of supp orting
di erent kinds of relationships b etween typ es However it has signi cant complexity and requires
good anticipation bytyp e sp eci ers to correctly cho ose the kind of typ e relationship that is needed
before any sub classes of the class in question are created The theoretical asp ects of the language
do not seem to b e fully develop ed as neither soundness nor decidabilityoftyp e checking has b een
proven To oL supp orts single dispatch Interface and implementation subtyping termed resp ectively
as subtyping and sub classing are di erentinTooL Parametric typ es can b e sp eci ed and the typ e
parameters can b e b ounded Information presented in GM is insu cient to judge the uniformity
and re exivityofthetyp e system however it seems to b e static and very expressive GM also
states that To oL is a p ersistent language however nothing else is said ab out its p ersistence The
p erformance of this typ e system with resp ect to the test suite is identicaltothatofthetyp e systems
of PolyTOIL and Lo op
The language TOFL QKB is a theoretical ob ject oriented functional language It has multiple
dispatch novariant argument rede nition function typ es and parametric typ es TOFL allows
subtyp e sp eci cations of the form if x is a subtyp e of Eq then list x isasubtyp e of Eq for any
typ e x All parametric typ es in TOFL are covariant except for functionals whicharenovariant
in their rst argument function argument p osition This is justi ed since TOFL is a functional
stateless language TOFL has a veri able and provably sound typ e system The TOFL typ e
system is also quite expressive as it passes the tests PERSON POINT SORT GENSORT APPLY
and the union part of the test SET
Conclusions
In this chapter the set of requirements for a typ e system of an ob ject oriented database programming
language was formulated In order to b e able to assess expressibilityofvarious typ e systems a set
of tests was develop ed A large numb er of existing typ e systems and languages was reviewed and
assessed according to their ability to satisfy the requirements and handle the test cases
Of the languages reviewed none was found to completely satisfy the requirements laid down in
Section None of the provably sound typ e systems has passed the ma jority of the tests However
every test was passed by at least one typ e system thus showing that the necessary mechanisms have
already b een develop ed It is their consistent and theoretically sound combination that remains
elusive so far
The typ e system presented in the next chapters is the result of my attempt to pro duce sucha
combination It was a challenging task and its solution will allow us to the develop a theoretically
sound re exive uniform and dynamic p ersistent ob ject oriented programming language
Chapter
The Typ e System Design
This chapter gives an informal description of the typ e system It illustrates the main ideas b ehind
the develop ed typ e system gives examples of its use and discusses design decisions The formal
treatment of the typ e system is given in Chapter
Functionality Behaviors Functions
Implementation functions
Implementation types Classes
Structure Types
Figure Typ e system layers
The typ e system consists of three sp eci cation layers Eachlayer consists of two comp onents
one deals with functionality dynamic comp onent and the other with structure static comp onent
This taxonomy is depicted in Figure
The most abstract layer consists of types abstract data and behaviors abstract functionality
This is the interface layer that has no concrete description of ob ject structure and functionality
This layer de nes the ob ject interface only and is primarily used for typ echecking purp oses It is
describ ed in Section
The intermediate layer consists of classes high level structure and functions high level co de
It is this layer that de nes most of the co de to b e executed when a program runs Classes are also
used for ob ject creation and extentmaintenance This layer is describ ed in Section
The lowest layer allows the programmer to use a low level language to sp ecify data and func
tionality This is the layer at whichmany system primitives are de ned An ordinary programmer
usually do es not need to know or care ab out the existence of this layer unless heavy optimization or
interop erability issues are involved This layer consists of implementation types and implementation
functions that will b e considered in Section
The three layer design is useful in shielding the user from the internal complexity of the system
Namely an ordinary user p osing queries against a database would only have to b e familiar with the
outermost layer typ es and b ehaviors An application programmer needs to know ab out the second
abstraction layer functions and classes in addition to the rst one Only a database administrator
implementor and designer should op erate at all the three layers using the implementation layer for
low level optimization and integration tasks The advantages of the three layer design are describ ed
in more detail in Section
In order to supp ort typ e system evolution most of the typ echecking presented here is designed
to b e invariant with resp ect to the covariant transformations describ ed in Section One of the
consequences of this feature is the lo calization of function co de typing A change in a function co de
do es not a ect the typing or validity of the program co de outside of the asso ciation that uses the
mo di ed function This is in contrast with ML style typ e inference systems where a lo cal change in
a function co de can p otentially a ect the typing of the co de outside the function The di erence lies
in the presence of explicit typ e annotations of b ehavior de nitions While typ e inferencing is still
p ossible in the presented system its scop e is restricted to a single asso ciation
The application of the principles and constructs describ ed in this chapter is given in Section
where an example of a basic typ e system designed for the TIGUKAT ob ject mo del Pet is dis
cussed
Typ es and b ehaviors
The notion of a type plays a central role in anytyp e system This section is devoted to typ es their
avors and the typ e sp eci cation issues Sp ecial attention is given to the issues related to subtyping
and typ e safety
Typ es are intro duced in Section Then in Section the notion of subtyping is discussed
Section o ers a detailed discussion of b ehavior sp eci cations rede nition and inheritance Sec
tions through discuss various typ e avors presentinthetyp e system Additional exibility
of constrained typ e sp eci cations is discussed in Section Interaction b etween subtyping and
inheritance is considered in Section Section concludes the discussion of this layer of
the typ e system
The notion of a typ e
In the typ e system presented here type denotes a concept The concept might originate from the
real world such as p erson or student mathematics integer numb er or set computer
science output stream or character or any other domain For instance a statement isan
integer numb er can b e rephrased as has typ e T Integer In the same way it is p ossible to
say john has typ e T Person meaning that John is a p erson
Each ob ject in a program has a typ e The typ e not only characterizes the conceptual prop erties
of an ob ject it also de nes its programmatic interface The presented typ e system is based on a
uniform behavioral object model Pet In this mo del everything is an ob ject and the only wayto
manipulate an ob ject is via behavior applications message sends function applications Therefore
the statement that the typ e de nes a programmatic interface for its ob jects is equivalent to the
statement that the typ e de nes a set of b ehaviors applicable to a particular ob ject The typ e can
also de ne implementations metho ds for one or more of its b ehaviors
Consider for example typ e T Person Ob jects of this typ e haveanage which is represented as
a natural numb er a name represented as a string and p ossibly a sp ouse another p erson The
de nition of a p erson typ e will have the following format
type T Person
age T Natural
name T String
spouse T Person
In the rest of the dissertation typ es will b e pre xed by T classes by C and implementation typ es by IT Also
a typewriter font will b e used to denote ob jects that o ccur in the program while normal font will b e used to denote
the real world ob jects and concepts they are designed to mo del This convention will b e followed through the rest of
the dissertation unless otherwise sp eci ed
Given this de nition the following b ehavior application is legal provided the typ e of john is
T Person john age It will return an ob ject of typ e T Natural
While simple this notion of a typ e has certain non trivial implications Some of them manifest
themselves when subtyping is considered they are discussed later An implication that is immediate
is the absence of ob ject structure de nition in a typ e Unlikemany other typ e systems the typ e
system discussed here totally separates ob ject interface from the ob ject structure An ob ject of typ e
T Person might b e implemented as a list of three slots holding age name and a sp ouse it might
also b e implementedasalistof ve slots holding date of birth rst second and middle names and
a sp ouse Both ob jects can legally and simultaneously b elong to the typ e T Person as long as they
provide the interface de ned in it The advantages of such separation as well as a more detailed
description of the mechanisms that achieve it will b e given in Section
Another implication of the notion of a typ e adopted here is the fact that a typ e is more than
just an interface In other words twotyp es can haveidentical interfaces and still b e considered un
related to each other Such an arrangement is termed as name equivalence as opp osed to structural
equivalence The structural equivalence principle states that twotyp es are equivalent and indis
tinguishable from each other if they haveidentical interfaces In order to illustrate the di erence
between the two approaches let us consider the following example
type T Person
age T Natural
name T String
type T Wine
age T Natural
name T String
Here typ es T Person and T Wine have identical interfaces Under the rules of name equivalence
these twotyp es are distinct and unrelated an attempt to bind a variable declared to b e of typ e
T Person to an ob ject of typ e T Wine will b e considered a compile time error On the other hand
if structural equivalence rules were in force such an assignmentwould b e considered legal since
in this case b oth T Person and T Wine would b e regarded as two di erent aliases for the same
entity theinterface The choice b etween name equivalence and structural equivalence is a design
decision Structural equivalence is more p ermissiveasitallows co de sharing b etween semantically
unrelated typ es On the other hand sometimes structural equivalence is to o p ermissive as in the
ab ove example Most of the real languages to day adopt name equivalence as the safer and more
transparent alternative Table Name equivalence and structural equivalence are two opp osite
ends of a sp ectrum of p ossible design decisions some intermediate approaches are also p ossible An
example of suchanintermediate approach is the notion of semantical or b ehavioral equivalence
NP LW LW In this approach equivalence is de ned in terms of observable b ehavior
While quite intuitive and app ealing this approach su ers from a ma jor drawback the notion of
b ehavioral equivalence is undecidable in general
Subtyping
The p owerofatyp e system comes in part from its ability to adequately mo del an application
domain In the real world concepts are not indep endentofeach other For example each student
is also a p erson an integer numb er can also b e considered as a sp ecial case of a real numb er In
Person order to mo del this relationship the typ e system provides a notion of subtyping Ifatyp e T
mo dels the concept of a p erson a typ e T Student mo dels the concept of a student and each
student isalsoaperson thenthetyp e T Student is called a subtype of the typ e T Person denoted
T Student T Person or type T Student subtype of T Person
What do es it mean for a typetobeasubtyp e of another one at a programming language level
Since every ob ject that b elongs to the rst typ e also b elongs to the second subsumption property a
student is a p erson it is natural to assume that an ob ject of a subtyp e can b e legally used everywhere
an ob ject of its sup ertyp e can This is termed the substitutability property and considered to b e one
of the most p owerful mechanisms for co de reuse in ob ject oriented programming
In the following example a typ e T Student is de ned as a subtyp e of the typ e T Person An
additional b ehavior studentId is de ned for this typ e
type T Person
age T Natural
name T String
spouse T Person
type T Student subtype of T Person
studentId T Natural
In the presence of these declarations the behavior applications aStudent age and
aStudent studentId are valid while aPerson studentId is not every student isalsoaperson
but not every p erson is a student
The term subtyping is sometimes used to denote inheritance Yet there is a considerable di erence
between these two notions Inheritance is the ability to reuse prop erties of a typ e interface co de
structure or anycombination of the ab ove in another typ e Inheritance do es not imply subtyping
but subtyping implies interface inheritance An inheriting typ e mayormay not b e a subtyp e
of the typ e it inherits from Thus inheritance is more general than subtyping On the other
hand subtyping guarantees substitutability inheritance do es not This is discussed further in
Section
The subtyping relationship b etween typ es de nes a partial order on the domain of typ es If
there are twotyp es T A and T B such that T A T B T B T A then T A T B Since subtyping is
user de ned the system has to verify that this condition is satis ed The presence of parametricity
makes suchchecking a non trivial task as discussed further in Section
Atyp e can subtyp e several typ es multiple subtyping This feature improves the expressibility
of the typ e system and allows straightforward de nitions of complicated typ e hierarchies Consider
for example the following typ e hierarchy
type T Person
age T Natural
name T String
spouse T Person
type T Student subtype of T Person
studentId T Natural
type T Teacher subtype of T Person
coursesTaught T Set T Course
type T TeachingAssistant subtype of T Student T Teacher
Here a teaching assistant is b oth a student and a teacher A teaching assistant is also a p erson so
age name and sp ouse apply Being also a student there is a student id b eing a teacher there is a
set of courses taught
While the situation describ ed here is not uncommon in practice manytyp e systems do not
allowmultiple subtyping Table The ma jor reason for this restriction is the fact that multiple
subtyping incurs signi cant complications for systems and languages where subtyping is coupled
with inheritance of co de and structure Multiple subtyping also makes typ e system theory and
dispatch signi cantly more complicated
It is assumed that aStudent evaluates to an ob ject of typ e T Student while aPerson evaluates to an ob ject of
Person typ e T
The typ e system presented in this dissertation has multiple subtyping as it increases the mo deling
power of the system Its theoretical treatment will b e discussed in Chapter
When a typ e system is used to design an application it is often necessary to add new sup er
typ es subtyp es or b ehaviors to existing typ es It is often desirable and sometimes required to do
these mo di cations without changing the original typespeci cations Most of to day s ob ject oriented
languages allow addition of subtyp es without touching the existing co de However addition of new
b ehaviors and or sup ertyp es can not b e done without changing the original sp eci cations
The presented typ e system is designed for database programming languages where the problem
of evolution is even more imp ortant then in traditional languages The ability to reuse legacy co de
while providing new typ es and b ehaviors is therefore crucial for the typ e system
The metho d that is used in the presented typ e system is based on speci cation combination there
can b e more then one sp eci cation of a single typ e and they are all glued together automatically
during compilation The same is true of all other sp eci cations used in the presented typ e system
Consider the situation when a typ e T Employee has b een de ned in a universitypayroll Later
on new typ es T Student and T TeachingAssistant havetobeintro duced into the system b ecause
it is b eing expanded to handle studentpayments as well The integrated application will haveto
pro duce sets where b oth employees and students are present moreover some b ehaviors previously
de ned for employees suchassalary have to handle students as well The following is the existing
sp eci cation
type T Employee
salary T Amount implementation
Using the sp eci cation combination metho d the following co de has to b e added
type T Person
name T String
salary T Amount
printSalary implementation name print salary print
type T Employee subtype of T Person
type T Student subtype of T Person
salary T Amount implementation
type T TeachingAssistant subtype of T Student T Employee
The addition of this co de to the co de ab ove will make T Person a common sup ertyp e of the old
typ e T Employee and the new typ e T Student Figure making it p ossible to op erate on sets of
p ersons for example the following co de would print salary information for all p eople in the database
provided that allStudents evaluates to the set of all students and allEmployees evaluates to the
set of all employees
T Set T Person allPeople allStudents union allEmployees
allPeople foreach printSalary
If this mechanism was not available the common sup ertyp e T Person could not b e created Then
the co de to print all names and salaries would not b e able to use union to automatically lter out the
duplicated teaching assistants and extra co de would have to b e written to supp ort this op eration
The imp ortance of the ability to create new sup ertyp es of existing typ es has b een discussed in H ol b inthe
context of interop erability T_Person
T_Employee T_Student
T_TeachingAssistant
Figure Person typ e hierarchy
Interface sp eci cation and pro duct typ es
The sp eci cation of the programmatic interface is the main comp onentofa typ e sp eci cation In
the previous sections some examples of interface sp eci cation have already b een considered In
the typ e system presented the interface consists of a set of behavior speci cations Each b ehavior
sp eci cation lists b ehavior argumenttyp es and sp eci es the return typ e For example the following
sp eci es the typ e T Real and its interface that consists of six b ehavior sp eci cations
type T Real
add T Real T Real
subtract T Real T Real
multiply T Real T Real
divide T Real T Real
negate T Real
The ab ove sp eci cation de nes the standard arithmetic op erations
Consider the following example where the typ e T ChequingAccount is de ned A customer can
dep osit or withdrawcashorcheques to from a chequing account and receive a transaction record
type T ChequingAccount
deposit T Cheque T TransactionRecord
deposit T Cash T TransactionRecord
withdraw T Cheque T TransactionRecord
withdraw T Cash T TransactionRecord
Here the b ehavior deposit has two di erentinterface sp eci cations Multiple interface sp eci cations
are allowed as long as they di er in their argumenttyp es A distinction in return typ es only is
disallowed for example the following sp eci cation is invalid
type T Account
deposit T Cheque T TransactionRecord
deposit T Cheque
Unit In the second case the return typ e is implicitly assumed to b e a sp ecial prede ned typ e T
which is analogous to typ e void in C Str and Java AG
In order to see why return typ e di erences are insu cient consider the following example
type T A
beh T C
beh T D
type T C subtype of T B
type T D subtype of T B
T A a
T B b
b a beh
Since at run time the ob ject b mayhave dynamic typ e T C or T D itisunclearwhich b ehavior
sp eci cation to use Both are legal and none is more sp eci c then the other In order to avoid this
kind of ambiguity it is required that b ehavior sp eci cations b e di erent in their argumenttyp es
When a subtyp e is de ned the interface sp eci cation inherited from its parent can b e mo di ed
These mo di cations should follow the return typecovariance rule in order for the newly de ned typ e
to b e a subtyp e of its parent The rule states that the return typeinabehavior sp eci cation for
asubtyp e should b e a subtyp e of the return typ e in the sp eci cation of the same b ehavior in its
parenttyp e For example the sp eci cation
type T Real
type T Integer subtype of T Real
succ T Integer
type T SmallInteger subtype of T Integer
type T Person
age T Integer
type T Child subtype of T Person
age T SmallInteger
is allowed while the sp eci cation
type T Person
age T Integer
type T Child subtype of T Person
age T Real
is not In order to see why this last sp eci cation is considered illegal consider the following co de
fragment
T Person p
T Integer i
p aChild the type of aChild is T Child
i p age
i i succ
Person This co de is typ e correct the rst assignmentistyp e correct since the static typ e of p is T
and the static typ e of aChild is T Child which is declared to b e a subtyp e of T Person The second
A more precise formulation of this rule will b e considered later in this section
Note that this sp eci cation is equivalent to an implementation of the test PERSON from the test suite given
in Section
assignmentistyp e correct since the return typ e of age de ned on the typ e T Person is T Integer
The third assignmentisalsotyp e correct as the return typ e of succ is T Integer On the other
hand at run time the second assignment will put a real numb er of typ e T Real into the variable
i since the b ehavior sp eci cation of age on the typ e T Child has return typ e T Real The call to
succ in the third assignment will then fail with a run time error since the b ehavior succ is not
de ned on T Real
Note that no restrictions are placed on the argument typ es In other words the following de ni
tion is legal
type T Real
add T Real T Real
type T Integer subtype of T Real
add T Integer T Integer
succ T Integer
While this de nition seems to b e natural its legality requires some explanation
A signi cantnumb er of ob ject oriented languages to dayuse single dispatch inwhich the metho d
to execute is chosen according to the typ e of the receiver Table In such languages the ab ove
sp eci cation with covariant arguments would not b e typ e safe In order to see why consider the
following co de fragment
type T Point
getX T Real
getY T Real
compare T Point x T Boolean implementation
return x getX getX
and x getY getY
type T ColorPoint subtype of T Point
getColor T Color
compare T ColorPoint x T Boolean implementation
return x getX getX
and x getY getY
and x getColor getColor
T Point p p
p aPoint
p aColorPoint
p compare p
If this typ e sp eci cation was considered to b e legal then the co de following it would b e typ e correct
ColorPoint is declared to b e a subtyp e of T Point and the assignments are typ e correct since T
application of compare is typ e correct since it compares twopoints The metho ds that implement
comparison are also typ e correct since they only rely on b ehaviors that are de ned on their argument
typ es However at run time the application of compare will b e dispatched to the metho d de ned
ColorPoint and it will fail at for color p oints according to the typ e of the receiver whichisT
run time since its argumentisoftyp e T Point which do es not de ne the b ehavior getColor
Therefore in all typ e safe single dispatched languages covariant sp eci cation of argumenttyp es is
disallowed However such sp eci cation is natural and desirable In order to use covariant argument
typ e sp eci cation safely multiple dispatch is required
In languages with multiple dispatch the metho d to invoke is determined according to the run
time typ es of al l arguments not just the receiver In such languages the ab ove example with p oints
and color p oints would not fail at run time b ecause the b ehavior application in question would b e
dispatched to the metho d de ned for p oints
The main idea b ehind multiple dispatch is the uniform treatment of all arguments While in
single dispatching languages the receiver has a sp ecial status multiply dispatching languages treat
all arguments as a single uni ed receiver This concept can b e neatly describ ed by using the notion
of a product type A pro duct typ e is a tuple of the form hT T i where T are simple non
n i
pro duct typ es Subtyping b etween pro duct typ es is induced by the subtyping b etween simple typ es
and is de ned as
def
hT T i hQ Q i m n T Q for all i n
n m i i
Now every b ehavior can b e considered as having a single argument the tuple of all arguments
de ned for it the rst b eing the original receiver Since every b ehavior is always applied to a
pro duct angle brackets are unnecessary and can usually b e omitted
It is p ossible to translate the standard ob ject oriented notation for b ehavior sp eci cation and
application into the pro duct typ e notation The pro duct typ e notation is mainly used for theoretical
purp oses but it is also useful for the description of multiple dispatch The following co de fragment
is a pro duct typ e translation of the p oint example ab ove
type T Point
getX T Point T Real
getY T Point T Real
compare T Point r T Point x T Boolean implementation
return getX x getX r
and getY x getY r
type T ColorPoint subtype of T Point
getColor T ColorPoint T Color
compare T ColorPoint r T ColorPoint x T Boolean implementation
return getX x getX r
and getY x getY r
and getColor x getColor r
T Point p p
p aPoint
p aColorPoint
compare p p
Pro duct typ e notation resembles a pro cedural notation however this is only a sup er cial sim
Point T Pointi ilarity Here the b ehavior compare has metho ds on two pro duct typ es hT
and hT ColorPoint T ColorPointi The run time argumenttyp e for the b ehavior application
ColorPoint T Pointi whichisasubtyp e of hT Point T Pointi but not compare p p is hT
a subtyp e of hT ColorPoint T ColorPointi according to Equation Therefore the metho d to
execute is the one de ned for p oints
Another illustrative example of pro duct typ e dispatch is the dispatchofthebehavior application
p compare p which will b e translated to pro duct typ e notation as compare p p Here
the run time typ e of the argumentis hT ColorPoint T ColorPointi whichisasubtyp e of b oth
hT ColorPoint T ColorPointi and hT Point T Pointi However since the pro duct typ e
This is an implementation of the test POINT from the test suite given in Section
is a subtyp e of the pro duct typ e the metho d asso ciated with the pro duct typ e is chosen
as the more sp eci c one Thus the b ehavior application p compare p will execute the co de
written for color p oint comparison as exp ected
Having reviewed pro duct typ e notation and dispatch we will now return to the sp eci cation of
real and integer numb ers Rewritten in a pro duct typ e notation the example sp eci cation is
type T Real
add T Real T Real T Real
subtract T Real T Real T Real
multiply T Real T Real T Real
divide T Real T Real T Real
negate T Real T Real
type T Integer subtype of T Real
add T Integer T Integer T Integer
subtract T Integer T Integer T Integer
multiply T Integer T Integer T Integer
negate T Integer T Integer
succ T Integer T Integer
Here there is no co de However in a pro duct typ e world not only the code to execute but also
the speci cation to use for typ echecking is chosen according to the pro duct typ e of the receiver
Consider the following co de
T Integer i i
i add i succ
In the pro duct notation the b ehavior application ab ovewillbe succ add i i Since
the static typ e of the tuple i i is hT Integer T Integeri b oth of the sp eci cations
add T Real T Real T Real and add T Integer T Integer T Integer are applicable
to it However the second one is more sp eci c than the rst and is therefore chosen for typ e
checking The result typ e of the second sp eci cation is T Integer and since the b ehavior succ is
de ned on this typ e the whole expression is considered to b e typ e correct
On the other hand the following co de will pro duce a typ e checking error
T Integer i
T Real r
i add r succ
In this case the call in question will translate to succ add i r and the static typ e of i r
Integer T Reali Therefore of the two sp eci cations for the b ehavior add only the rst one is hT
will do the second requires that the receiver typ e b e a subtyp e of h T Integer T Integeri and the
typ e of i r is not The rst sp eci cation has a return typ e T Real but the b ehavior succ is not
de ned on T Real and the typ echecking rep orts an error This is the exp ected result as adding an
integer to a real yields a real numb er and the successor function is not de ned on reals
The ab ove sp eci cation of typ es T Integer and T Real can b e signi cantly simpli ed by the
use of selftype which is a reference to the de ning typ e that changes covariantly along the typ e
hierarchy The following is a non pro duct sp eci cation that uses selftype
type T Real
add selftype selftype
A more formal treatmentof selftype will b e given in Section
subtract selftype selftype
multiply selftype selftype
divide selftype T Real
negate selftype
type T Integer subtype of T Real
succ T Integer
Note that the result typ e of the b ehavior divide is sp eci ed as T Real not as selftype Ifitwas
sp eci ed a selftype the inherited de nition in T Integer would b e
type T Integer subtype of T Real
divide selftype selftype
which means that an integer divided byaninteger is always an integer which is not the case
Therefore the result typ e of divide has not b een changed to selftype
Usage of selftype in argumenttyp es is known to b e statically typ e unsafe in languages with
single dispatch Cas a BG However itissoconvenient that some language designers chose to
drop static typ e safetyinfavor of it e g Ei el Mey while others chose to drop substitutability
e g LOOM BFP However in a multiply dispatching language covariant sp eci cation is typ e
safe so it is p ossible to have it all use of selftype typ e safety and substitutability Cas a BG
With the intro duction of pro duct typ e notation it is now p ossible to give a precise formulation
for the return typ e covariance rule discussed at the b eginning of this section The rule is as follows
for anytwo sp eci cations of the same b ehavior if the pro duct receiver typ e of the rst b ehavior
sp eci cation is a subtyp e of the pro duct receiver typ e of the second sp eci cation then the return
typ e of the rst sp eci cation should b e a subtyp e of the return typ e of the second Thus the
following is allowed
type T Cash
type T SmallAmountOfCash subtype of T Cash
type T TransactionRecord
type T SimplifiedTransactionRecord subtype of T TransactionRecord
type T Account
deposit T Cash T TransactionRecord
deposit T SmallAmountOfCash T SimplifiedTransactionRecord
This would not b e allowed if T SimplifiedTransactionRecord was not declared to b e a subtyp e of
TransactionRecord since in pro duct notation the two b ehavior sp eci cations would read T
deposit T Account T Cash T TransactionRecord
deposit T Account T SmallAmountOfCash T SimplifiedTransactionRecord
Account T SmallAmountOfCashi hT Account T Cashi it should also b e true that Since hT
T SimplifiedTransactionRecord T TransactionRecord otherwise the rule would b e violated
In this section the interface sp eci cations were discussed The problem of b ehavior rede nitions
was considered and its solution was outlined The notions of multiple dispatch and product type
notation were intro duced and used to illustrate the mechanisms b ehind the b ehavior rede nition
semantics adopted in the presented typ e system
Behavior typ es
Before the intro duction of the ob ject oriented programming paradigm data types were considered
as ob ject structure de nitions This p oint of view is present in pro cedural programming languages
suchasPascal JW as well as in database programming where the set of data structure de
nitions for a database is called its schema As the ob ject oriented programming paradigm gained
p opularity the fo cus of data ob ject sp eci cations has b een slowly shifting from ob ject structure
to ob ject functionality In the ob ject oriented programming mo del the functionality is the ma jor
characteristic while the ob ject structure plays a secondary role
An ob ject structure sp eci cation describ es the logical interpretation of the physical storage the
ob ject o ccupies On the other hand sp eci cation of ob ject functionality fo cuses on the things one
can do with a particular ob ject i e the set of actions b ehaviors messages functions that can b e
p erformed applied on a particular ob ject
A unit of structure sp eci cation is therefore a eld de nition A eld de nition describ es b oth the
amountofphysical memory allo cated for a eld and its logical treatment At the same time a unit
of functionality sp eci cation is an action b ehavior message Here the action declaration b ehavior
sp eci cation can b e viewed as b eing parallel to the logical eld typ e abstract interpretation while
the action de nition metho d function co de can b e considered parallel to the physical layout of a
particular eld concrete interpretation Thus the relationship b etween an action declaration and
an action de nition is parallel to the relationship b etween eld typ e and its physical layout
It is therefore natural to consider the b ehavior sp eci cation as a typ e of the b ehavior for which
such a sp eci cation is given In other words when a b ehavior b is sp eci ed as b eing applicable to a
certain typ e T t such sp eci cation contains information ab out b oth the typ e T t and the b ehavior
b Note that the parallel b etween actions and elds go es even further the simplest p ossible concrete
interpretation of elds binary bits is capable of representing any information via binary numb ers
while the simplest p ossible concrete interpretation of actions terms is capable of representing
any computation via calculus Tur
When b ehavior sp eci cations are considered as typ es b ehaviors themselves b ecome ob jects
Such an arrangement leads to a truly uniform mo del in which all entities including actions are
ob jects This allows one to extend the notions of subtyping and substitutability to b ehavior typ es
a T r where T a is an argument and b ehaviors The standard notation for b ehavior typ es is T
typ e while T r is the result typeofabehavior For example the typ e T Real T Real is the typ e of
functions that pro duce a real result when applied to a real numb er In the example syntax adopted
here the same b ehavior typ e can also b e written as T Real T Real which is parallel to the
syntax of b ehavior sp eci cations
Consider the following sp eci cation
type T Real
negate T Real
const T Real r
which is equivalentto
type T Real
negate T Real T Real
const T Real r
in pro duct typ e notation This can b e considered as an abbreviation for
type T Real
const T Real T Real negate
const T Real r
that de nes twotyp ed constants negate of typ e T Real T Real and r of typ e T Real This last
sp eci cation is in turn equivalentto
type T Real
const T Real T Real negate
const T Real r
Behavior typ es are not atomic they are comp osed from other typ es using the b ehavior typ e
constructor or equivalently much the same way as pro duct typ es are comp osed of other
typ es using the typ e constructor hi Therefore it is relevant to de ne the subtyping rules for
the b ehavior typ es based on the subtyping relationship b etween their comp onents The general
subtyping rule for b ehavior typ es is as follows
def
A R A R A A R R
Note that the relationship b etween argumenttyp es is reversed In order to see why this is the case
consider the following example
type T Real
truncate T Integer
type T Integer subtype of T Real
succ T Integer
T Real T Integer rifunc
T Integer T Integer iifunc
iifunc truncate
iifunc
rifunc succ Compile time type error
rifunc
Here twovariables rifunc and iifunc are de ned The rst one is declared to b e of
typ e T Real T Integer while the second one is de ned to b e of typ e T Integer T Integer
Constants b ehaviors truncate and succ are de ned to b e of typ es T Real T Integer and
Integer T Integer resp ectively The rst assignment in the ab ove co de is statically typ e T
correct since
Real T Integer T Integer T Integer typ e of iifunc typ e of truncate T
according to the Equation The subsequent application of the b ehavior stored in the variable
iifunc to the integer constant is also statically typ e correct since the argumenttyp e of iifunc
is declared to b e T Integer When this b ehavior application is executed truncate is applied to an
integer This is typ e correct b ecause truncate is declared to op erate on any real numb er and an
integer is a real
On the other hand the assignmentofsucc to the variable rifunc is not statically typ e correct
since it is not true that
typ e of succ T Integer T Integer T Real T Integer typ e of rifunc
If this assignmentwas allowed the subsequent application of rifunc to the real number would
fail at run time as the b ehavior succ is not designed to work on real numb ers
So far a single b ehavior sp eci cation was used in the examples to sp ecify a typ e of a b ehavior
However a b ehavior can have several sp eci cations Section In this case the typ e of a
b ehavior is de ned as the greatest lower bound glb of the typ es given by these sp eci cations
Consider the following sp eci cation
This fact is usually formulated as follows The typ e constructor is contravariant in its rst p osition
type T Real
add T Real T Real
type T Integer subtype of T Real
add T Integer T Integer
or in pro duct typ e notation with b ehavior typ es
type T Real
const T Real T Real T Real add
type T Integer subtype of T Real
const T Integer T Integer T Integer add
The two sp eci cations of the b ehavior constant add are combined and the resulting sp eci cation is
type T Real
type T Integer subtype of T Real
const glb T Real T Real T Real T Integer T Integer T Integer add
Thus the resulting typ e of add is
glb h T Real T Reali T Real hT Integer T Integeri T Integer
This expression can b e understo o d as follows the b ehavior add pro duces a real result when applied
to a pair of real numb ers and an integer result when applied to a pair of integer numb ers A
b ehavior application add pro duces an integer result while b ehavior applications add
add and add pro duce real results This is so b ecause only the pro duct typ e
of the argument of the rst b ehavior application is a subtyp e of h T Integer T Integeri while all
Real T Reali four of the pro duct typ es of the arguments of these applications are subtyp es of hT
Therefore the results of all four applications are known to b e subtyp es of T Real while the result
of the rst b ehavior application is additionally known to b e a subtyp e of T Integer
Consider the following piece of co de provided that the ab ove sp eci cation of the b ehavior add
is in e ect
T Real T Real T Real rrfunc
T Integer T Integer T Integer iifunc
rrfunc add
rrfunc
iifunc add
iifunc
When the assignmentofthebehavior constant add to the variables rrfunc and iifunc is typ e
checked the combined typ e of the b ehavior add is taken into account Therefore b oth assignments
typ e check
RR hT Real T Reali T Real and T II hT Integer T Integeri T Integer Then Let T
typ e of add glb T RR T II T RR typ e of rrfunc
RR T II T II typ e of iifunc typ e of add glb T
Note that in the absence of greatest lower b ounds the ab ovecodewould not typ e check if the typ e
T RR was assigned to the b ehavior add then the assignment iifunc add would not typ echeck
on the other hand using the typ e T II for the typ e of add would not allowustotyp e check the
assignment rrfunc add Only the combination of these twotyp es in the form of the greatest
lower b ound enables successful typ echecking of b oth assignments
In this section the notion of a behavior type has b een intro duced Prop erties of b ehavior typ es and
their usage were discussed and the principle of combining b ehavior typ es from di erent sp eci cations
using the greatest lower b ound was considered All these notions will b e given a formal treatment
in Chapter
Mutable typ es
The ability to de ne any computation in the applicative functional stateless paradigm has led to
the developmentofanumb er of programming languages These languages share several imp ortant
prop erties strict and rigorously de ned semantics simplicity of the main programming paradigm
and well established theoretical mechanisms for reasoning ab out programs On the other hand the
biggest disadvantage of these languages from a practical p ersp ective is exactly the same feature that
makes them so attractive from the theoretical viewp oint the inability to deal with state
While there are certain applications that can b e programmed without using the concept of state
most real world applications rely on the ability of a program to store and retrieve data This is
esp ecially true of database applications as database data have a life span b eyond the execution time
of a program Therefore if a program is unable to deal with state change the data in a database
can never b e up dated
The abilityofa typ e system to deal with mutable data is essential for database programming
However many languages with well develop ed and theoretically sound typ e systems either do not
consider mutable data at all or severely restrict their use Section
The ML language MTH is a representative example of the languages in the last category Itis
based on the functional programming paradigm but provides some imp erative features in the form
of its referencetypeconstructor ref However due to the problems related to typing of imp erative
features in a functional environment the use of the referencecel ls in ML is much more restricted
than the use of all other typ e constructors An excellent review of this problem is given in App
In imp erative ob ject oriented programming languages the concept of state is usually captured
bytwo separate but related notions the notion of an attribute and the notion of a variable An
attribute is a slot inside an ob ject that is capable of holding an ob ject or an ob ject reference of
a particular typ e An ob ject can b e put into an attribute assignedtoit or extracted from it A
variable is similar to an attribute in its ability to hold an ob ject On the other hand while an
attribute is a part of an ob ject a variable is not
Here only the issues related to typing of b ehaviors that are used to access or set attributes will
b e discussed The discussion of the other asp ects of state suchastyping of lo cal variables de nition
of ob ject structure using a set of attributes and its relationship to the b ehavioral interface et cetera
app ears in Section
In the prop osed typ e system setting an attribute or a variable is an ordinary b ehavior
application The assignment syntax aPerson age is considered as an abbreviation for
aPerson set age which is in turn an abbreviation for set age aPerson The attribute
sp eci cation in this system b elongs to a class not a type thetyp e only sp eci es the interface for
getting and setting the attributes This corresp onds to the absence of public instance variables
The advantages of this approach will b e discussed later in Section Here a familiar notation for
sp ecifying an attribute interface as a part of a typ e will b e intro duced and the typing implications
of this mechanism will b e discussed
The following sp eci cation
type T Person
age T Natural
name T String
sp eci es a typ e T Person that has two assignable attributes a name and an age Note here the
sign that is used to separate the b ehavior arguments from its result typ e It is a combination
of the sign used to sp ecify the return typ e for immutablebehaviors and the sign used for
assignment The sp eci cation age T Natural is also p ossible it means that a p erson s age
can not b e read but it can b e assigned to
The ab ove sp eci cation makes the following b ehavior applications legal
T Person p
p age p age add
p name John
The typ e sp eci cation for T Person given ab ove is equivalentto
type T Person
age T Person T Natural
set age T Person T Natural
name T Person T String
set name T Person T String
and the b ehavior applications are translated into
T Person p
set age p add age p
set name p John
Thus the standard pro duct typ e typing rules describ ed in Section apply to assignmentaswell
A more complicated example of user de ned assignment is the de nition of the b ehavior at that
is capable of getting the n th element of a list It is also p ossible to assign to an element as in the
following co de
type T MutableList
at T Natural T Object
T MutableList mlist
mlist at print
mlist at object
The translation of this co de fragmentis
type T MutableList
at T MutableList T Natural T Object
set at T MutableList T Natural T Object
T MutableList mlist
print at mlist
set at mlist object
The rst b ehavior application prints the fourth elementofanarray while the second b ehavior appli
cation sets it to object Thus the treatment of assignment prop osed here allows the programmer
It is more precise to de ne T MutableList as a parametric type parameterized by the typ e of its elements Such
a sp eci cation will b e considered in Section
to sp ecify custom versions of the assignment op eration including the p ossibility of using additional
arguments
The standard subtyping rule for up datable attributes requires their typing to b e novariant The
following examples illustrate the reasons b ehind this requirement while the subsequent discussion
demonstrates how the attribute novariance requirements are relaxed in the prop osed typ e system
Consider the following sp eci cation
type T SmallNatural subtype of T Natural
type T Person
age T Natural
type T Child subtype of T Person
age T SmallNatural
Twotyp es are sp eci ed T Person and T Child with an up datable attribute age A p erson s age
is a natural numb er while a child s age is a small natural number a subtyp e of natural If the
attribute age was immutable such an arrangementwould b e p erfectly legal However the mutable
nature of this attribute causes a problem that manifests itself in the typing of the following co de
T Person aPerson
T Child aChild
T Natural n
aPerson aChild
aPerson age n
The ab ovecodeistyp e correct However after its execution the age attribute of aChild will contain
a natural numb er rather than a small natural one whichcontradicts the sp eci cation of the attribute
age Situations like the one presented in this example are the primary reason for the novariance
requirement for mutable attributes in current ob ject oriented typ e systems
On the other hand there are situations in which the novariance requirement is to o strict Con
sider the following sp eci cation
type T CharacterList
substring T Natural start T Natural end T CharacterList
type T String subtype of T CharacterList
substring T Natural start T Natural end T String
translateFromFrench T String
It allows for the following co de to b e successfully typ echecked
T String string
T CharacterList list
string pteit mluot
string substring ul The resulting string
will contain pteit mulot
list e t
string substring list The resulting string
will contain petit mulot
string substring translateFromFrench The result will be the
translation of petit i e small
It is assumed that numb ering of arrays and strings starts from not from
If the novariance requirementwas in force the rede nition of substring in the typ e T String would
b e disallowed Then the last b ehavior application that p erforms the translation would not typ e
check as the result typ e of substring would b e considered to b e T CharacterList whichdoesnot
have b ehavior translateFromFrench de ned on it
The co de ab ove is legal and do es not cause any run time errors In order to see why the covariant
rede nition in the rst example causes problems while the one in the second example do es not details
of pro duct typ e sp eci cations havetobetaken into account In the rst example the translation
will give the b ehavior set age the typ e
glb T Person T Natural T Unit T Child T SmallNatural T Unit
which implies that the b ehavior application set age aChild n where the typ e of aChild is
T Child andatyp e of n is T Natural istyp e correct This is so b ecause the pro duct typ e of
the argumentis hT Child T Naturali whichisasubtyp e of hT Person T Naturali However
which co de should b e executed when suchabehavior application is encountered Apparently the
co de that just stores n in the appropriate slot of the ob ject aChild would b e typ e incorrect On
the other hand if co de was provided that caps the natural argumenttomake it a small natural
b efore storing it into the slot the ab ovebehavior application would not cause the run time error
In the presented typ e system such an alternative code can be provided byusingkeyword in the
asso ciation Therefore it is not the behavior speci cation that is incorrect rather it is the implicit
assumption that the corresp onding co de directly stores the value into the slot Such an implicit
assumption is never made in the second example b ecause it do es not resemble structure de nition
as much as the rst one do es In other words it is not the typ e sp eci cation that fails here it is
our intuition
Based on the ab ove discussion it is concluded that this problem can not and should not b e
dealt with at the typeandbehavior speci cation level but only at the code and structure de nition
level If the twolevels interface and structure de nitions were coupled as they are in manyof
to day s programming languages the novariance constraintwould have to b e enforced However
inatyp e system that provides a clean separation b etween these two levels of abstraction like the
one presented here the novariance restriction can b e lifted at the higher level of b ehavior and typ e
sp eci cation This will b e discussed further in Section
In this section mutable typ e sp eci cations were discussed A p owerful user de ned assignment
sp eci cation mechanism was intro duced and its usage as well as its translation to pro duct typ e
sp eci cations were considered The novariance condition usually placed on mutable typ es was also
discussed it was concluded that such a restriction is unnecessary at the typ e level for a typ e system
that provides a clean separation b etween interface and structure de nitions
Parametric typ es and b ehaviors sp eci cation
Parametricity is one of the most p owerful mechanisms used for precise typ e sp eci cation Parametric
polymorphism that is presentintyp e systems that supp ort parametricity is comparable in p ower to
inclusion polymorphism which is due to subtyping and interface inheritance
The distinction b etween the two kinds of p olymorphism is blurred in typ e systems with structural
subtyping BETA MMPN Strongtalk BG TM BBdB ML MTH and its clones On
the other hand the designers of typ e systems with user de ned non structural subtyping usually
fo cus on only one of the two forms of p olymorphism supp orting the other one only minimally For
example the typ e systems of Ada Ada and Napier MMPN fo cus primarily on parametric
p olymorphism while the typ e systems of more traditional ob ject oriented languages C Str
and clones Java AG fo cus on inclusion p olymorphism Attempts to combine the full p ower
of parametric and inclusion p olymorphisms result in loss of substitutability safety or decidable
typ echecking Java clones Transframe Sha Cecil Cha and clones The only typ e system
that combines safety substitutability decidable typ echecking expressive parametric and inclusion
p olymorphism and user de ned subtyping is ML BM a However ML restricts user de ned
subtypingtotyp es within the same type class a set of typ es with the same number of typ e arguments
and the same kind of subtyping relationships b etween them has a limited ability to deal with
mutable typ es like other ML clones and do es not provide separation b etween di erent sp eci cation
levels interface and implementation
The typ e system presented in this dissertation is unique in that it combines all of the ab ove
prop erties The parametricityinteracts with all the comp onents of the typ e system making its
consistent design a non trivial task Suchinteractions will b e considered in this section along with
examples showing the p otential problems stemming from these interactions
Consider the example of the sp eci cation of the typ e T List
type T List
at T Natural T
cat T List T List
Here at extracts the n th element from the list while cat concatenates two lists In typ e systems
that do not supp ort parametricitythetyp e T is usually sp eci ed to b e T Object a sup ertyp e
of all typ es However this leads to the container problem exempli ed by the following co de
type T Person
age T Natural
T List list
T Person person person person
list person person person
list at age print
Here the last b ehavior application is considered to b e illegal b ecause the typ e checker only has
enough information to conclude that the result of list at will b e T Object and the b ehavior
age is not applicable to just ob jects it is only applicable to p ersons Thus in this case the ab ove
typ e sp eci cation is to o restrictive
On the other hand consider the co de fragment
type T Person
age T Natural
type T Wine
age T Natural
T List aWineList
T List aPersonList
T Person person person person
T Wine wine wine wine
aPersonList person person person
aWineList wine wine wine
aPersonList aPersonList cat aWineList
The last assignment will store a mix of p ersons and wines in the variable aPersonList a semanti
cally incorrect action However the typ echecker can not detect this incorrectness as its knowledge of
List One the typ e of the variables aPersonList and aWineList is limited to the generic list typ e T
PersonList and T WineList can attempt to make the sp eci cation more strict by sp ecifying typ es T
as unrelated subtyp es of T List
type T List
at T Natural T Object
cat T List T List
type T PersonList subtype of T List
at T Natural T Person
cat T PersonList T PersonList
type T WineList subtype of T List
at T Natural T Wine
cat T WineList T WineList
T PersonList aPersonList
T WineList aWineList
T Person person person person
T Wine wine wine wine
aPersonList person person person
aWineList wine wine wine
aPersonList aPersonList cat aWineList
Then the assignment in question will b ecome typ e incorrect as the result of concatenation of a list of
p ersons and a list of wines will havetyp e T List which is not a subtyp e of T PersonList However
this approach requires a programmer to explicitly de ne list typ es for every p ossible elementtyp e
an activitywhich is b oth tedious and error prone
In order to provide static typ e safety in a clear and concise manner the following parametric
typespeci cation can b e utilized
type T List X
at T Natural X
cat T List X T List X
The sp eci cation of the typ e T List nowhasa typeparameter X The co de in question will b e
T List T Person aPersonList
T List T Wine aWineList
T Person person person person
T Wine wine wine wine
aPersonList person person person
aWineList wine wine wine
aPersonList aPersonList cat aWineList
and the last assignment will not typ e check Coming back to the container problem example now
the co de
type T Person
age T Natural
T List T Person list
T Person person person person
list person person person
list at age print
will typ echeck as the typ echecker knows that the result typ e of list at is T Person rather than
just T Object
The numb er of parameters is not limited to one for example it is p ossible to sp ecify a dictionary
typeasfollows
type T MutableDictionary KeyType ValueType
at KeyType ValueType
allKeys T List KeyType
allValues T List ValueType
and use it in co de like the following
T MutableDictionary T String T Person mdict
T Person p p
p mdict at John
mdict at Peter p
Parameters do not necessarily havetobetyp es they are only required to come from some
lattice a partially ordered domain with lower and upp er b ounds As an example consider an array
typ e that has a numb er of elements as one of its parameters
type T Array ElementType T Natural UpperBound
at T Natural ElementType
This de nes a parametric typ e T Array with two parameters The rst parameter is called
ElementType it represents the typ e of array elements The second one is called UpperBound it
represents the numb er of elements in the array Since the second parameter is a natural number
rather than a typ e its sp eci cation includes the typ e sp eci er T Natural
In this section the parametric typ e sp eci cations were describ ed The next question related to
parametric typ es is related to the sp eci cation of subtyping rules b etween them Is the typ e of a
list of students a subtyp e of the typ e of a list of p ersons Can a parametric typ e b e a subtyp e of a
non parametric one or vice versa The answers to these questions are given in the next section
Parametricity and subtyping
Each parametric typ e sp eci cation de nes a family of parametric typ es that di er only in their
parameters Therefore the issue of subtyping parametric typ es can b e divided into two the issue
of intra family subtyping and that of inter family subtyping
Intra family relationships
Intra family subtyping is a subtyping relationship b etween typ es that b elong to the same parametric
typ e family Consider an immutable list typ e sp eci ed as
type T List X
at T Natural X
cat T List X T List X
Let a typ e T Student be a subtyp e of T Person Then every student is also a p erson therefore a
list of students can also b e considered as a list of p ersons since each element of the former can b e
considered a p erson In general it is desirable to have a rule that sp eci es an intra family subtyping
relationship in terms of the relationships b etween parameter typ es the same wayitwas sp eci ed
for pro duct Equation and b ehavior Equation typ es In particular for the immutable list
typ es it is desirable to have the following rule
def
List X T List Y X Y T
I e the immutablelisttyp es are covariant in their rst and only argument This is sp eci ed as
type T List covar X
at T Natural X
cat T List X T List X
where the keyword covar is used to denote the covariance of the typ e parameter X
Consider the following co de
T List T Person aPersonList
T List T Student aStudentList
aPersonList aStudentList cat aPersonList Ok
aStudentList aStudentList cat aPersonList Type error
aStudentList aStudentList cat aStudentList Ok
aPersonList aStudentList cat aStudentList Ok
All these assignments are typ e correct except for the second one This is the exp ected result since a
mix of students and p ersons can also b e considered as a list of p ersons every student is a p erson
while it cannot b e considered a list of students not every p erson is a student On the other hand
a list of students can b e considered to b e a list of p ersons
In order to see howthetyp e checker arrives at this conclusion the b ehavior pro duct typ e trans
lation of the ab ove sp eci cation has to b e considered
type T List covar X
const T List X T Natural X at
const T List X T List X T List X cat
Thus for a b ehavior application cat l l to b e valid there should exist a typ e X such that
htyp e of l typ e of l i hT List X T List X i
and the result of this b ehavior application will then havetyp e T List X Since the ab ove statement
is true for all typ es X that satisfy the ab ove condition the actual result typ e T R has to b e less than
T List X for all such X This is equivalent to the statement that
T R glb fX j X satis es Equation g
Getting back to our example the rst b ehavior application aStudentList cat aPersonList
or cat aStudentList aPersonList in pro duct notation has argument pro duct typ e
hT List T Student T List T Person i Therefore the set of typ es X that satisfy Equation
is fT Persong The ab ove is due to covariance of T List T List T Student T List T Person
b ecause T Student T Person The greatest lower b ound of this set is T Person and therefore
the result typ e of this b ehavior application is T List T Person which can b e safely assigned
to the variable of typ e T List T Person the rst assignment but not to the variable of typ e
T List T Student the second assignment
On the other hand the set of typ es X that satisfy Equation for the second b ehavior appli
cation aStudentList cat aStudentList will b e fT Person T Studentg its greatest lower b ound
is T Student therefore the result typ e of this b ehavior application is T List T Student that can
safely b e assigned to a variable of typ e T List T Person the third assignment as well as to a
variable of typ e T List T Student the fourth assignment
The ab ove example dealt with a covariant typ e sp eci cation and an immutable list typ e What
happ ens when a mutable list typ e is considered Suchatyp e can no longer b e covariant since the
resulting typ e sp eci cation would b e unsound If it was allowed the following co de would typ echeck
type T Person
type T Student subtype of T Person
studentId T Natural
type T MutableList covar X
at T Natural X
T MutableList T Student aStudentList
T Person aPerson
aStudentList at aPerson Should be a type error
aStudentList at studentId
This co de however will fail at run time since the b ehavior studentId is not de ned on p ersons
The following is the reason whytyp e checking of the assignment succeeds In pro duct b ehavior
typ e notation the ab ovewould read as
const T MutableList X T Natural X at
const T MutableList X T Natural X T Unit set at
T MutableList T Student aStudentList
T Person aPerson
set at aStudentList aPerson Should be a type error
The set of typ es X such that
argumenttyp e hT MutableList T Student T Natural T Personi
hT MutableList X T Natural Xi argumen ts for which set at is de ned
Persong Indeed will b e fT
hT MutableList T Student T Natural T Personi
hT MutableList T Person T Natural T Personi
according to the subtyping rule for pro duct typ es Equation and due to the covariance of list
sp eci cation that gives
T MutableList T Student T MutableList T Person
This is the same situation as the one considered in Section if the co de that is written to
implement set at is just storing its argumentinto the array it is not typ e correct In order to b e
able to write suchcodeinatyp e safe manner the de nition of the parametric typ e T MutableList
should b e novariant
type T Person
type T Student subtype of T Person
studentId T Natural
type T MutableList novar X
at T Natural X
T MutableList T Student aStudentList
T Person aPerson
aStudentList at aPerson Type error
aStudentList at studentId
The parametric typ e T MutableList is now de ned as novariant keyword novar which means
that none of the mutable list typ es is a subtyp e of the other no matter which relationship exists
between the typ e parameters of these list typ es
The typ echecking of this co de fails b ecause Equation that led to successful typ echecking of
the ab ovecodeincovariantmutable list sp eci cation is no longer true for novariant sp eci cation
Why should a mutable list typebenovariant Informally the typ e T MutableList T Student
can not b e a subtyp e of T MutableList T Person since the second one can accept into it any
p erson while the rst one can not On the other hand the typ e T MutableList T Person can
not b e a subtyp e of T MutableList T Student b ecause student s b ehaviors can b e applied to an
ob ject extracted from the list of the second typ e while suchbehaviors can not b e applied to an
ob ject extracted from the list of the rst typ e
So far covariant and novariant sp eci cations have b een considered The third p ossibility a
contravariant sp eci cation keyword contravar also exists The following typ e sp eci cation uses
contravariance to correctly typ e output streams
type T OutputStream contravar X
put X
Note usage of the sp eci er in the sp eci cation of b ehavior put it means that this b ehavior can
not b e accessed but only assignedto Contravariance means that
def
T OutputStream X T OutputStream Y Y X
note the reversed direction of subtyping
Informally b oth a student and a p erson can b e put into an output stream of p ersons a student
is a p erson however only students can b e put into an output stream of students Therefore an
output stream of p ersons can do the same as an output stream of students accept students plus
more accept p ersons Thus the typ e of output streams of p ersons should b e a subtyp e of the typ e
of output streams of students
Therefore in the following co de fragment
type T Person
type T Student subtype of T Person
T OutputStream T Student aStudentOS
T OutputStream T Person aPersonOS
T Person aPerson
T Student aStudent
aPersonOS put aPerson Ok
aPersonOS put aStudent Ok
aStudentOS put aPerson Type error
aStudentOS put aStudent Ok
all assignments are typ e correct except for the third one as it attempts to output a p erson to a
stream designed for students
In general read only entities likeimmutable lists are covariant write only entities like output
streams are contravariant and read and write entities likemutable lists are novariant
Behavior typ es are examples of a parametric typ e family with twotyp e parameters The rst of
these parameters argument or input typ e is contravariant while the second one result or output
typ e is covariant Equation Thus the b ehavior typ e discussed earlier in Section can b e
sp eci ed as
type contravar ArgType covar ResType
apply ArgType ResType
This sp eci cation allows a programmer to use the b ehavior apply to apply b ehaviors to their ar
guments This is typ e safe b ehavioral re ection It also shows how higher order b ehaviors can b e
sp eci ed
Pro duct typ es considered in Section can also b e sp eci ed as parametric typ es in whichall
parameters are covariant Equation
Parametric typ es are also used for lo cal variable typ e sp eci cation The typ e implicitly used for
Var de ned as follows lo cal variables is a novarianttyp e T
type T Var novar X
val X
Whenever a lo cal variable de nition of the form T aType aName is encountered itistrans
lated into const T Var T aType aName Every assignmenttothislocalvariable of the form
aName anExpression is translated into aName val anExpression Every other access to
alocalvariable aName is translated into aName val The result is of course sub ject to normal
pro duct typ e pro cessing and expansion
For example the following co de
type T Person
age T Natural
type T Student subtype of T Person
T Person aPerson
T Student aStudent
aPerson aStudent
aPerson age print
in fully expanded form b ecomes
type T Person
const T Person T Natural age
type T Student subtype of T Person
const T Var T Person aPerson
const T Var T Student aStudent
set val aPerson aStudent
print age val aPerson
The typ echecking algorithm is therefore free from any sp ecial treatmentoflocalvariables they
are simply regarded as ob jects of one of the T Var typ es The syntactic transformations describ ed
This is an implementation of APPLY test
ab ove do not allow the variables to escap e from their scop e as there is no syntactic waytorefer
to a variable as an ob ject It is straightforward to verify that these transformations indeed give the
intended meaning to the notion and typing of lo cal variables This will b e formalized in Chapter
In this section intra family subtyping was considered Concepts of covariance contravariance
and novariance were discussed and examples of their use were presented It has also b een shown
that intra familysubtyping is su cient for de nition of the fundamental typ es of the prop osed typ e
system as well as for handling of lo cal variables This prop erty demonstrates the p ower and re exive
capabilities of the presented typ e system
Inter family relationships
Another asp ect of subtyping related to parametric typ es is inter family subtyping It o ccurs when
a subtyping relationship is established b etween parametric typ es from di erent families
Consider the following sp eci cation
type T Set covar X
isMember X T Boolean
union T Set X T Set X
type T List covar X subtype of T Set X
at T Natural X
It declares the typ e T List X to b e a subtyp e of T Set X for every typ e X For example the
following co de is typ e correct
T List T Student aStudentList
T Set T Person aPersonSet
aPersonSet aPersonSet union aStudentList
The pro duct typ e argumenttyp e of the b ehavior application ab oveisoftyp e hT Set T Person
T List T Student i The minimal typ e X suchthat
Set T Person T List T Student i hT Set X T Set X i hT
as required by the sp eci cation of the b ehavior union is X T Person since
T List T Student T Set T Student T Set T Person X
Set T Person which is assignable Therefore the result typ e of the b ehavior application ab oveisT
to a variable of the same typ e
In the ab ove example b oth typ es participating in inter family subtyping relationship had the
same number of typ e parameters with the same variance sp eci cation covar None of the ab ove
is required bythetyp e system For example all of the following sp eci cations are allowed
type T Set covar X
type T EmptySet subtype of T Set X
type T List covar X
type T String subtype of T List T Character
type T UpdatableList novar X subtype of T List X
type T InputStream covar X
get X
type T OutputStream contravar X
put X
type T IOStream novar X subtype of T InputStream X T OutputStream X
These sp eci cations de ne an emptysettyp e that is a common subtyp e of all set typ es a string
typ e whichisasubtyp e of the typ e of character lists and an input output stream typ e whichisa
subtyp e of appropriate input and output stream typ es
Person and its subtyp e T Student is An example streams typ e hierarchy for parameter typ es T
depicted in Figure Note that this is an implementation of the test STREAMS from the test
suite given in Section
T_InputStream(T_Person) T_OutputStream(T_Student)
T_InputStream(T_Student) T_OutputStream(T_Person)
T_IOStream(T_Student) T_IOStream(T_Person)
Figure Stream typ es
Not every set of p ossibly parametric subtyp e declarations results in a valid typ e system For
example the typ e sp eci cation
type T MutableList novar X subtype of T Strange
type T Strange subtype of T MutableList T Person
is incorrect since there exists a cycle
Strange T MutableList T Person T Strange T
In order to avoid situations like these the following restriction is enforced Let the user typegraph
G b e de ned as follows for every parametric typ e family with constructor T X there is a vertex
T X in G For every subtyp e sp eci cation of the form T X T Y there is a directed
edge from T X to T Y in G
Rule Acyclicity The user typ e graph G is acyclic
For example the user typ e graph for the ab ovetyp e hierarchy will lo ok as follows
Strange T MutableList This graph clearly contains a cycle and therefore this typ e hierarchy T
is rejected
One of the applications of inter family parametric typ e sp eci cations is F bounded quanti cation
CCH which can b e e ectively used for sp eci cation of binary methods Binary metho ds are
b ehaviors with two arguments with identical typ es their sp eci cation has always b een a challenge
for ob ject oriented typ e systems BCC
Consider the following situation COMPARABLE test from the test suite given in Section
Number with unrelated subtyp es T Real and T Radix Assume it is necessary to sp ecify typ es T
and T Date with comparison metho ds such that comparing twonumbers or two dates b etween each
other is legal while their cross comparison is not A standard way of de ning a typ e T Comparable
do es not work b ecause it is to o p ermissive For example in the following co de
Person are considered ary constructors Simple typ es like T
type T Comparable
less selftype T Boolean
type T Number subtype of T Comparable
type T Date subtype of T Comparable
T Number n
T Date d
n less d Should have been a type error
the b ehavior application n less d is typ e correct This is the case b ecause the pro duct argument
typ e for this b ehavior application is hT Number T Datei which is a subtyp e of hT Comparable
T Comparablei that sp eci es one of the argument pro duct typ es where the b ehavior less is de ned
The problem can b e solved by using F b ounded p olymorphism CCH and parametricity The
following typ e sp eci cation
type T Comparable contravarX
less selftype T Boolean
type T Number subtype of T Comparable T Number
type T Real subtype of T Number
type T Radix subtype of T Number
type T Date subtype of T Comparable T Date
describ es the necessary typ e hierarchywhich is depicted in Figure
T_Comparable(T_Real) T_Comparable(T_Radix)
T_Comparable(T_Number) T_Comparable(T_Date)
T_Number T_Date
T_Real T_Radix
Figure Comparable typ es
Comparable is contravariant in its only parameter The following is the Note that the typ e T
argumentinfavor of contravariance in this case If an ob ject of a typ e T can b e compared to an
ob ject of typ e X then it can also b e compared to an ob ject of any subtyp e Y of X For example
since a real number T T Real can b e compared to anynumber X T Number it can also b e
Radix Thus for all typ es T X andY compared to a radix number Y T
T T Comparable X Y X T T Comparable Y
Let s put T T Comparable X Then
Comparable X T Comparable Y X Y Y X T
which is the de nition of contravariance
With the comparable typ e sp eci cation given ab ove the co de
T Number n
T Real re
T Radix ra
T Date d d
n less re
re less ra
ra less n
d less d
will b e successfully typ echecked while the co de
T Number n
T Date d
d less n
will b e rejected
In this section the interactions b etween parametricity and subtyping were considered Both
intra family and inter family relationships were discussed and their p ower was illustrated bya
numb er of examples It was shown that the mechanisms describ ed in this section are p owerful enough
to de ne b ehavior typing variable typing and F b ounded quanti cation In the next section the
extension of the return typ e covariance rule discussed in Section for the case of parametric
typ es will b e considered
Parametricityandinterface sp eci cation
In the presented typ e system there are several rules that are imp osed up on the user typ e sp eci
cations One of them is the requirement of acyclicity of the user typ e graph G Section the
other is the return typ e covariance rule Section
The return typ e covariance rule was formulated only for simple non parametric typ es A
re nement of this rule for parametric typ es is required Parametric sp eci cations can intro duce new
problems related to return typ e covariance as can b e seen in the following co de
type T Var novar X
val X
type T Object
makeRef T Var selftype
type T Person subtype of T Object
T Object object
It is assumed that the dynamic type of aPerson is T Person
and the dynamic type of anObject is T Object
object aPerson
object makeRef val anObject Dynamic type error
Here b oth assignments are statically typ e correct However the second assignment is dynamically
incorrect since it tries to put anObject inside of a p erson reference created bythebehavior applica
tion object makeRef The latter creates a person reference rather than an object reference since
Person the dynamic typ e of object is T
The problem here is related to the sp eci cation of the b ehavior makeRef The expanded pro duct
typ e de nition of this b ehavior for typ es T Object and T Person yields
const T Object T Var T Object makeRef
const T Person T Var T Person makeRef
which contradicts the return typ e covariance rule The direct expansion used here is only done for
illustrative purp oses since full expansion is in most cases in nite
Therefore the return typ e covariance rule has to b e reformulated to deal with parametric sp eci
cations directly The following is the desired formulation
n
Rule Return typ e covariance If fA B g are the sp eci
i n i n
i i
i
cations for a b ehavior b then
i
n
i n
i
B B A A
i n i i n i
i i
n n
i i
i j i j
n
i n
j
A A B B
i n j i n j
i n i n
j j
where A denotes a parametric typ e with parameters
n n
i i
This rule will b e further re ned in Chapter De nitions and to deal with constrained
typ es
The de nition of the b ehavior makeRef do es not satisfy Rule since its pro duct typ e sp eci
cation is T Var and for T Person T Object the rst condition is violated
A T Person T Object A
B T Var T Var T Person T Var T Object T Var B
In ML MTH the typ e constructor ref is de ned similarly to the de nition of makeRef and
T Var ab ove in ML a typ e constructor plays a dual role it is used for b oth typ e sp eci cation and
run time ob ject creation Therefore its usage causes problems The ML solution to this problem is
to treat this typ e constructor sp ecially severely restricting its p olymorphism In the presented typ e
system no sp ecial treatment is required for anytyp e constructor and the e ect of ref as a typ e
constructor is accomplished using the mutable typ es considered in Section
In this section the extension of the return typ e covariance rule for the case of parametric sp ec
i cations has b een presented Several examples illustrating the necessity and use of the extended
rule have b een considered
Union and intersection typ es
One of the unique features of database programming languages is the incorp oration of query facilities
Queries are declarative side e ect free computations that are usually based on a variant of SQL
Queries require precise and adequate typing of set theoretic and applicative op erations suchas
union intersection map etc
With the help of parametric typ es it is p ossible to de ne the b ehavior union on the typ e of
immutable sets T Set in suchaway that it indeed has the desired prop erties
type T Set covar X
union T Set X T Set X
What happ ens if a union of a set of students and a set of p ersons is attempted Such b ehavior
Set T Student T Set Person i a pro duct application will have a pro duct typ e argumenttyp e h T
Indeed T Var T Person is not a subtyp e of T Var T Object as T Var is novariant
In ob ject query mo dels a query may not necessarily b e side e ect free however this do es not a ect query typing
typ e in the sp eci cation of union is hT Set X T Set X i and the greatest lower b ound of typ es X
suchthat
hT Set T Student T Set Person i hT Set X T Set X i
Person Therefore the result typ e of the application will b e T Set T Person It is easy is X T
to show that the result typ e of an application of the b ehavior union to two sets with elementtyp es
A and B will always b e T Set lub A B precise typing for the set theoretic union op eration
The sp eci cation of b ehavior map is also p ossible using parametric and b ehavior typ es
type T Set covar X
map X Y T Set Y
The b ehavior map takes an argument whichisabehavior applicable to the elements of the set and
returns the set of results of applying this b ehavior element wise to the elements of the source set
For example
type T Real
negate T Real
T Set T Real s
s
s s map negate After the assignment s will be
Only the sp eci cation of the b ehavior intersect causes problems The result typ e of this
b ehavior should b e the greatest lower b ound of the argumenttyp es b ecause the resulting set contains
only those ob jects that b elong to the two argument sets at once The presented typ e system provides
a programmer with an abilitytousetyp e op erators glb and lub explicitly in typ e sp eci cations Using
these additional capabilities the immutable set typ e can b e sp eci ed as follows
type T Set covar X
union T Set Y T Set lub X Y
intersection T Set Y T Set glb X Y
map X Y T Set Y
Note that the sp eci cation of union given here is equivalent to the sp eci cation given ab ove How
ever it describ es the programmer s intentions more explicitly and is therefore preferable
Using typ e sp eci ers glb and lub together with parametric and b ehavior typ es makes it p ossible
to sp ecify set theoretic op erations with an adequate precision The mechanisms used here are not
designed just for sets they can b e used for all typ es including user de ned ones This is in contrast
to the approach taken in Machiavelli BO and Fib onacci AGO where precise typing of set
theoretic op erations is also p ossible but the treatment of sets is sp ecial and the programmer can
not de ne new typ es with analogous typing precision
Constrained sp eci cations
The parametric typ e sp eci cations considered so far were unconstrained in that anytyp e could b e
used as their parameter However sometimes a parametric typ e only makes sense for some parameter
typ es and not for all of them In order to sp ecify such conditions typeconstraints are utilized
The following is a sp eci cation of a typ e T OrderedSet that requires that its elements b e com
parable with each other
type T OrderedSet covar X
where X subtype of T Comparable X
subtype of T Set X
maximals T Set X
minimals T Set X
This sp eci cation requires the typ e parameter X to b e comparable It also sp eci es that ordered sets
are subtyp es of sets The b ehaviors maximals and minimals are de ned to return sets of maximal
and minimal elements of the set Ordered sets are sets and therefore all op erations de ned for sets
are also applicable to them
Typ e constraints can also b e used to sp ecify b ehaviors For example if the typ e of ordered sets is
intro duced just to de ne b ehaviors maximals and minimals then it is p ossible to do without it and
de ne the ab ove b ehaviors on sets by adding the appropriate typ e constraints to their de nitions
type T Set covar X
maximals T Set X where X subtype of T Comparable X
minimals T Set X where X subtype of T Comparable X
This sp eci cation however do es not allow one to declare variables of ordered set typ es while the
previous one did
Constraints that can b e used for typ e or b ehavior sp eci cation should not contain variables that
are not used in the rest of the sp eci cation They must also b e monotonic Monotonicityhere
means that typ e constraints must b e constructed in a way that do es not violate substitutability
The following is an example of how a non monotonic constraint can result in a loss of typ e safety
type T Employed
type T CEO subtype of T Employed
type T Company
fire X where T Employed subtype of X X subtype of T Employed
T Company c
T Employed e
T CEO ceo
e ceo Ok
c fire e Run time error
The b ehavior fire is only applicable to employed p ersons that are not CEOs the sp eci cation
says that the argumentofthisbehavior must havetyp e T Employed andT CEO is not equal to
T Employed The code above is statically typ e correct e is just an employed p erson and so can
b e red but fails at run time when an attempt is made to re ceo The reason for this failure is
non monotonicity of the constraint placed on the sp eci cation of the b ehavior fire an employed
p erson satis es it but a CEO do es not even though a CEO is an employed p erson
In order to sp ecify monotonicity requirements a new translation step b esides the pro duct typ e
translation is intro duced The purp ose of this step is to add any constraints implicitly sp eci ed for
selftype to the constraint set Every b ehavior sp eci cation that has an o ccurrence of selftype is
translated as follows
All o ccurrences of selftype are replaced byafreshtyp e variable S
A constraint S subtype of T where T is a typ e where the b ehavior is de ned is
added to the list of typ e constraints for that b ehavior
For every typ e T that de nes a constraint that constraint is added to all b ehavior sp eci cations
where typ e T T o ccurs
For example the full translation of the sp eci cation of the typ e of ordered sets given ab ove
will b e
type T OrderedSet covar X
where X subtype of T Comparable X
subtype of T Set X
const T OrderedSet X T Set X
where X subtype of T Comparable X maximals
const T OrderedSet X T Set X
where X subtype of T Comparable X minimals
while the translation of the typ e sp eci cation of real numbers typ e
type T Real
add selftype selftype
subtract selftype selftype
multiply selftype selftype
divide selftype T Real
negate selftype
will b e
type T Real
const S S S where S subtype of T Real add
const S S S where S subtype of T Real subtract
const S S S where S subtype of T Real multiply
const S S T Real where S subtype of T Real divide
const S S where S subtype of T Real negate
Now the monotonicity requirement can b e de ned It has two parts one deals with typ e sp ec
i cation constraints and the other with constraints placed on b ehaviors If a set of constraints
C is placed on a typ e sp eci cation of a typ e T then monotonicity requires
n n
that
C T T C
n n n n n n
OrderedSet is monotonic as Thus the constraint placed on the sp eci cation of T
T Comparable T OrderedSet T OrderedSet
T Comparable T Comparable
T Comparable
due to covariance of T OrderedSet and contravariance of T Comparable
If a set of constraints C isplacedonabehavior sp eci cation
n
A R
n n
then monotonicity requires that
C A A C
n n n n n n
Thus the constraint placed on the b ehavior sp eci cation of maximals is monotonic the same pro of
as for the previous example while the one placed on fire is not
These monotonicity conditions will b e given a more formal treatment in Chapter
In this section constraints and constrained sp eci cations were considered The monotonicity
conditions that the constraints must satisfy have b een formulated and illustrated
Subtyping and inheritance
While subtyping is a very p owerful concept sometimes it is to o restrictive There are cases when
it is necessary to reuse an interface without creating a subtyp e An example of such situation is
demonstrated by the LIST test from Section where a single linked list no de typ e and a double
linked list no de typ e havetobespeci ed
The straightforward approach to this problem
type T LinkedListNode
getNext selftype
attach selftype
type T DoubleLinkedListNode subtype of T LinkedListNode
getPrev selftype
attachLeft selftype
is unsatisfactory b ecause it allows no des of di erenttyp es to b e mixed in a single list This is so b e
cause T DoubleLinkedListNode is sp eci ed as a subtyp e of T LinkedListNode and can therefore b e
used everywhere a linked list no de can b e used including a single linked list If a programmer do es
not wanttoallow this b ehavior the ab ove sp eci cation will not do In this case F b ounded p oly
morphism CCH can b e used This solution is analogous to the solution of the COMPARABLE
problem presented in Section
type T LinkedListNodeInterface novar X
getNext X
attach X
type T LinkedListNode subtype of T LinkedListNodeInterface T LinkedListNode
type T DoubleLinkedListNode
subtype of T LinkedListNodeInterface T DoubleLinkedListNode
getPrev T DoubleLinkedListNode
attachLeft T DoubleLinkedListNode
This solution is typ e correct and gives the intended typ e semantics to b oth no de typ es However it
is not nearly as elegant as the solution based on matching BFP Another way of representing this
situation will b e given in Section where class extension rather than subtyping will b e utilized
Conclusions
In this section the typ e and b ehavior sp eci cations were describ ed The use of subtyping pro duct
typ es b ehavior typ es parametric typ es and constrained typ es was illustrated and discussed Sev
eral transformation techniques used to translate the user de ned sp eci cations into a more basic
primitive notation were intro duced Examples considered in this section show that the presented
typ e system is capable of typing all tests from Section without sacri cing substitutability static
typ e safety and decidable typ echecking as will b e shown in Chapter
Typ e and b ehavior sp eci cations form the most abstract layer of the prop osed typ e system
since they deal only with interfaces ignoring ob ject structure the co de implementing b ehaviors
and underlying physical memory layout The middle layer of the presented typ e system consists of
classes that describ e ob ject structure and functions that implement b ehaviors This layer will b e
considered in the next section
Except for the BROWSER test that will b e discussed in the next section
Classes and functions
Interfaces play an imp ortant role in ob ject oriented programming Yet an interface sp eci cation is
insu cient for programming since b oth ob ject structure and co de implementing the interfaces for a
particular structure has to b e sp eci ed b efore a program can b e successfully translated compiled or
interpreted The intermediate layer of abstraction which consists of classes structure and function
co de sp eci cations is designed for this purp ose
In this section classes and functions will b e describ ed Issues related to dispatch will also b e
discussed Connections b etween the intermediate layer of abstraction and the higher interface
layer such as corresp ondence b etween classes and typ es b ehaviors and functions and typ echecking
issues will also b e elab orated
Classes
While typ es denote concepts at a very abstract level classes give a more concrete structural view of
ob jects used in a program Every ob ject b elongs to a class as no material ob ject can exist without
a structure A typ e may b e implemented by a single class or by several di erent classes or it may
not b e implemented at all an abstract type Classes sp ecify ob ject structure at an intermediate
level they are not as abstract as typ es yet they are abstract enough not to sp ecify a particular
physical memory layout for the ob jects that b elong to the class The following is an example class
sp eci cation
type T Person
age T Natural
name T String
class C Person implements T Person
T Natural age
T String name
age implementation age
name implementation name
The class C Person implements the typ e T Person thebehavior age is implemented by the attribute
age and the b ehavior name is implemented by the attribute name This implementation of the
typ e T Person is rather trivial while the next example shows a non trivial implementation of the
same typ e
class C Person Names implements T Person
T Natural age
T String firstName
T String secondName
T String middleName
age implementation age
name T String implementation fun
return firstName middleName secondName
name T String implementation fun arg
firstName arg columnSeparatedBySpaces
middleName arg columnSeparatedBySpaces
secondName arg columnSeparatedBySpaces
The notation attr will b e used for attributes to distinguish them from b ehaviors
Here a p erson is implemented by a class with four attributes The rst one corresp onds to a p erson s
age while the other three represent di erentcomponents of a p erson s name Therefore the b ehavior
name can no longer b e implemented as a simple attribute access instead it is implemented as a pair
of anonymous functions whose b o dies are written in curly braces Two functions are necessary
b ecause the b ehavior name was sp eci ed as assignable token One function is used to access
the name and the other is used to set it
It is p erfectly legal for a program to have b oth C Person and C Person Names implementing the
same typ e T Person Ob jects of b oth classes can exist simultaneously in the program Only the
programmer of the p erson classes needs to know ab out them Users only need to see the typ e For
example the following co de
T Person person
person name John A Smith
person age print
person name print
will work for ob jects of b oth p erson classes Moreover it will also work for any class that implements
the typ e T Person
The ability of the co de ab ovetowork correctly for all p ossible implementations of T Person is a
consequence of using just types and not classes for variable and argumenttyp e sp eci cations Since
the co de never refers to an actual ob ject structure class only the interface sp eci ed byatyp e is
used for typ echecking Successfully typ echecked co de therefore relies on interface only and do es not
need to b e changed if the ob ject structure changes
This prop ertyisvery imp ortant for co de reuse in evolving systems such as database applications
where the legacy co de constitutes a signi cant p ortion of overall application co de When data
structure evolves the legacy co de is still valid and do es not havetoberewritten
The only place where classes are implicitly used for argument sp eci cation is the co de of functions
written for a particular class The functions implementing b ehaviors in a class need to access
attributes of that class Therefore the implicit rst argument of those functions the receiver is
implicitly typ ed by the enclosing class For the purp oses of typ echecking a class translates to a
sp ecial kind of typ e while an attribute translates into a pair of b ehaviors one for getting and the
other for setting the value of the attribute b eing translated
For example the sp eci cation of the class C Person Names given ab ove will b e translated into
type T Person
age T Natural
set age T Natural
name T String
set name T String
type C Person Names subtype of T Person
translation of the attribute age
age T Natural implementation fun system defined code
set age T Natural implementation fun arg system defined code
translation of the attribute firstName
firstName T String implementation fun system defined code
set firstName T String implementation fun arg system defined code
translation of the attribute secondName
secondName T String implementation fun system defined code
set secondName T String implementation fun arg system defined code
translation of the attribute middleName
middleName T String implementation fun system defined code
set middleName T String implementation fun arg system defined code
age implementation fun return age
set age T Natural implementation fun x age x
name implementation fun
return firstName middleName secondName
set name T Natural implementation fun arg
firstName arg columnSeparatedBySpaces
middleName arg columnSeparatedBySpaces
secondName arg columnSeparatedBySpaces
after class and assignment expansion The implementation clauses are the association speci cations
they sp ecify the co de function that is asso ciated to a particular b ehavior on arguments of a
particular typ e Functions asso ciations and issues related to their consistency will b e discussed in
Section
In the ab ove example it has b een shown how the class sp eci cations can b e translated into
typ e sp eci cations for typ e checking purp oses It also shows that classes C Person Names are
translated into subtyp es of the typ es they implement T Person so an ob ject of such a class can
b e used everywhere its typ e is required
While a typ e can b e implemented by several classes a class always implements a single typ e A
family of parametric typ es can b e implemented by a family of parametric classes For example the
following sp eci es the family of classes C Set X that implements the family of parametric typ es
Set X T
type T Set covar X
isElement X T Boolean
union T Set X T Set X
class C Set X implements T Set X
const T List X list
The set is implemented as a list Since sets are immutable the attribute list was sp eci ed as
constant sp eci er const thus disallowing assignment to the attribute This sp eci cation allows for
list is sp eci ed to haveatype T List X and will thus work extensive reuse since the attribute
with any p ossible implementation of a list
The parametric class sp eci cation is not as elab orate as the parametric typ e sp eci cation as
each class has to corresp ond to a single typ e Thus the following class sp eci cation is illegal
class C Set implements T Set X
Set corresp ond to al l typ es T Set X The ab ove restriction is imp ortant since since it would make C
classes are resp onsible for object creation If a class could corresp ond to several typ es the typ e of
an ob ject created via that class would b e ambiguous
Another way of parameterizing a class is by explicit use of selftype For example the following
is a sp eci cation of a linked list no de class
type T LinkedListNode
getNext selftype
attach selftype
class C LinkedListNode implements T LinkedListNode
selftype next
getNext selftype implementation next
attach selftype implementation
The resulting class C LinkedListNode has a mutable attribute next that is typ ed by selftype
The reason for the use of selftype instead of plain T LinkedListNode will b e apparent when the
notions of subclassing and class extension are intro duced in the next section
Sub classing and class extension
Just as subtyping is used to achieve inclusion p olymorphism when typ es are concerned subclassing
can b e used to achieve the same e ect for classes Sub classing as well as subtyping implies substi
tutability and the sub classing semantics is the semantics of subtyping given by the translation of
classes to typ es intro duced in the previous section For example the following is a sp eci cation of
the class C Student as a sub class of C Person
type T Person
age T Natural
name T String
class C Person implements T Person
T Natural age
T String name
age implementation age
name implementation name
type T Student subtype of T Person
studentId T Natural
class C Student subclass of C Person implements T Student
T Natural studentId
studentId implementation studentId
The class C Student has the same attributes as the p erson class C Person as well as the additional
attribute studentId In this case the typ e T Student whichisasubtyp e of T Person is imple
mented by a sub class C Student of the class C Person This relationship is neither necessary nor
required For example the following sp eci es unrelated classes for the same twotyp es
type T Person
age T Natural
name T String
class C Person implements T Person
T Natural age
T String name
age implementation age
name implementation name
type T Student subtype of T Person
studentId T Natural
class C Student Names implements T Student
T Natural age
T String firstName
T String secondName
T String middleName
T Natural studentId
age implementation age
name T Natural implementation fun
return firstName middleName secondName
name T Natural implementation fun arg
firstName arg columnSeparatedBySpaces
middleName arg columnSeparatedBySpaces
secondName arg columnSeparatedBySpaces
studentId implementation studentId
Thus subtyping do es not imply sub classing but sub classing do es imply subtyping
This de nition of sub classing is parallel to the de nition of subtyping Traditionally however
the term subclassing denotes the notion of class extension inwhich only the structure is inherited
and no subtyping or substitutability is required In the presented typ e system class extension is a
mechanism for such structure reuse It do es not imply substitutabilityorsubtyping The need for a
relationship that is weaker than subtyping stems from the fact that mutable attributes are novariant
Section For example the following sp eci cation is incorrect
type T Person
age T Natural
name T String
class C Person implements T Person
T Natural age
T String name
type T Child
age T SmallNatural
name T String
favoriteToys T Set T Toy
class C Child subclass of C Person implements T Child
T SmallNatural age
T Set T Toy ftoys
since the class C Child rede nes mutable attribute age and therefore can not b e used everywhere
the class C Person is used
However the following sp eci cation is allowed
type T Person
age T Natural
name T String
class C Person implements T Person
T Natural age
T String name
type T Child
age T SmallNatural
name T String
favoriteToys T Set T Toy
class C Child extends C Person implements T Child
T SmallNatural age
T Set T Toy ftoys
In this sp eci cation the class C Child extends the class C Person rather than subclasses it Therefore
it is p ossible to rede ne the attribute age while inheriting the attribute name with no mo di cation
In the presented typ e system class extension is understo o d as textual rewriting of the class with
automatic substitution of explicit and implicit o ccurrences of selftype in the style of PS The
de nitions given in the extending class override the de nitions of the class b eing extended just like
the de nition of the attribute age in the ab ove example A class can extend several classes and
the con icts have to b e explicitly resolved by the programmer Since class extension do es not imply
subtyping the co de inherited from the class b eing extended needs to b e retyp echecked in the context
of the extending class
The following is the example of usage of class extension along with the selftype mechanism
type T LinkedListNode
getNext selftype
attach selftype
class C LinkedListNode implements T LinkedListNode
selftype next
getNext selftype implementation next
attach selftype implementation
type T DoubleLinkedListNode
getNext selftype
getPrev selftype
attach selftype
attachLeft selftype
class C DoubleLinkedListNode
extends C LinkedListNode
implements T DoubleLinkedListNode
selftype prev
getPrev implementation prev
attachLeft selftype implementation
DoubleLinkedListNode is not a subtyp e of T LinkedListNode and the Even though the typ e T
class C DoubleLinkedListNode is not a sub class of C LinkedListNode it is still p ossible to reuse
the co de and sp eci cation of the former in the sp eci cation of the latter The programmer do es
not need to rewrite the co de if a subtyp e can not b e pro duced since class extension can b e used
to avoid co de duplication the implementations of b ehaviors attach and next and the attribute
next are inherited from C LinkedNodeType Note that this is another solution of the LIST test
Section whichisinmanyways more elegant and concise than the one given in Section
Class extension need not b e parallel to subtyping in fact they can legally go in opp osite direc
tions Consider the sp eci cation of circles and ellipses A circle is a ellipse and therefore its typ e
should b e a subtyp e of that of an ellipse From the structural p ointofview however a circle can
b e represented bycenter and radius ma jor axis while for an ellipse center ma jor axis and minor
axis are needed Therefore the structure of an ellipse is an extension of the structure of a circle
We assume that the ma jor axis is always parallel to X axis Otherwise an additional attribute would b e required
This situation is extremely di cult to mo del in most of the to day s typ e systems and languages
Yet it can b e elegantly represented in the typ e system describ ed here
type T Ellipse
center T Point
majorAxis T Length
minorAxis T Length
type T Circle subtype of T Ellipse
class C Circle implements T Circle
T Point center
T Length majorAxis
center implementation center
majorAxis implementation majorAxis
minorAxis implementation majorAxis
class C Ellipse extends C Circle implements T Ellipse
T Length minorAxis
minorAxis implementation minorAxis
Note how the same attribute majorAxis is used in the class C Circle to implement b oth majorAxis
and minorAxis b ehaviors and how the implementation of minorAxis is overridden in C Ellipse to
refer to the new attribute minorAxis instead This sp eci cation allows circles to b e used everywhere
ellipses can b e used yet it allows the structure of circles to b e reused for ellipses
In this section b oth sub classing and class extension have b een describ ed Their use was illus
trated byseveral examples It has also b een shown how class sp eci cations are transformed into
typ e de nitions for typ echecking purp oses
Ob ject creation and extent maintenance
Classes not only de ne the ob ject structure they are also used to create ob jects In fact ob jects
can only b e created via classes Since classes themselves are ob jects the ob ject creation is done by
applying the creation b ehavior new to the class ob ject There are two di erences b etween ob ject
creation and regular b ehavior application First the creation b ehavior is prede ned and do es not
haveany arguments Second when a class is explicitly used the constructor expression can b e
used to initialize its attributes b oth mutable and immutable This is imp ortant as only construc
tor expressions can put values into immutable attributes Consider the following example where
immutable circles and ellipses are de ned
type T Ellipse
center T Point
majorAxis T Length
minorAxis T Length
type T Circle subtype of T Ellipse
class C Circle implements T Circle
const T Point center
const T Length majorAxis
center implementation center
majorAxis implementation majorAxis
As a C programmer the author has encounterednumerous situations of this kind Every time either typ e
safety or co de reuse had to b e compromised
minorAxis implementation majorAxis
class C Ellipse extends C Circle implements T Ellipse
const T Length minorAxis
minorAxis implementation minorAxis
Then the following would create a circle with a unit radius
T Circle aCircle new C Circle
center new C Point
majorAxis
The inability to rede ne b ehavior new is not nearly as serious a restriction as it seems to b e Consider
the following sp eci cation of a p erson typ e and class
type T Person
age T Natural
name T String
class C Person implements T Person
T Natural age
T String name
name implementation name
age implementation age
initialize T Natural initAge T String initName implementation
if initName isEmpty or initAge isEmpty then
raise incorrectInit
age initAge
name initName
Create a new person
T Person aPerson new C Person initialize John Smith
Note that the b ehavior initialize is de ned in the class C Person rather than in its typ e This
means that the b ehavior initialize can only b e legally used on ob jects whose class is statically
Person Since classes can not b e explicitly used for any sp eci cation the only time known to b e C
the class is statically known is when the ob ject has just b een created as in the example ab ove
Classes are also used for extent maintenance Most of the classes maintain a collection of all their
ob jects the extent automatically The extent can b e used to query over all ob jects of a sp eci ed
class The b ehavior extent is de ned on classes to return a set of their ob jects It can b e used as
follows
Print all persons created so far
C Person extent foreach print
Not all classes allow ob ject creation or supp ort ob ject maintenance In fact there is a taxonomy
of classes Regular classes supp ort ob ject creation and maintain their extents Finite classes supp ort
extents but do not allow ob ject creation classes of characters and b o oleans are examples of nite
classes Manual classes allow ob ject creation but do not automatically supp ort their extents e g
classes of lists and sets Finally in nite classes supp ort neither extent nor ob ject creation suchas
classes of real and integer numb ers T_InfiniteClass(X)
T_ManualClass(X) T_FiniteClass(X)
T_Class(X)
Figure Class typ e hierarchy
Since classes are ob jects the ab ove taxonomy can b e neatly expressed in terms of the typ e
hierarchy of classes
type T InfiniteClass covar X
type T FiniteClass covar X subtype of T InfiniteClass X
extent T Set X
type T ManualClass covar X subtype of T InfiniteClass X
new X
type T Class covar X subtype of T ManualClass X T FiniteClass X
When a class is sp eci ed an appropriate ob ject of one of the ab ovetyp es is created The class typ e
hierarchy is depicted in Figure
Classes representanintermediate layer of structure sp eci cation Their functional counterparts
at the intermediate layer are functions considered in the next section
Functions and asso ciations
Behaviors are abstract entities They describ e functionality at the highest level via signatures For
the actual computation however signatures can not b e used and therefore more concrete function
ality sp eci cation has to b e provided In the presented typ e system functions play this role A
function de nes functionality via a co de fragment that is executed when the function is invoked
The co de that is used in functions is comp osed of a sequence of b ehavior applications Inside
the co de lo cal variable declarations and certain control statements are allowed For the purp oses
of typ echecking only assignment return and typeif discussed later statements are of interest
The following is an example function
fun x
T Integer result
result x age age
return result
This function can not b e typ echecked since it sp eci es neither its argument nor return typ e However
functions do not exist by themselves Before a function can b e used it has to b e associated with
a particular b ehavior on a set of argumenttyp es This is an example asso ciation
type T Person
age T Natural
Except for closures discussed later
ageDifference T Person x T Integer implementation
fun x This line can be omitted as it can be
inferred from the behavior signature
T Integer result
result x age age
return result
This asso ciation can b e typ echecked to determine whether the function conforms to the signature
of the b ehavior it is asso ciated with The issues of typ echecking are discussed in Chapter and
its formal underpinnings in Chapter An informal overview of typ echecking and typ e system
capabilities was already given in Section therefore in this section only issues sp eci c to function
asso ciations dispatch and sp ecial statements will b e discussed
A function can also b e asso ciated with a b ehavioronaclass instead of a typ e Such a function
has access to class attributes as in the following example
type T Person
age T Natural
name T String
class C Person Names implements T Person
T Natural age
T String firstName
T String secondName
T String middleName
age implementation age
name T String implementation fun
return firstName middleName secondName
name T String implementation fun arg
firstName arg columnSeparatedBySpaces
middleName arg columnSeparatedBySpaces
secondName arg columnSeparatedBySpaces
Here the functions that implementthetwo set and get branches of the b ehavior name are asso ciated
with these branches on the class C Person Names
Note that the ability to asso ciate functions with b oth typ es and classes is an extension of a
standard ob ject oriented mo del For example Java AG supp orts separation b etween typ es in
terfaces and classes However it only allows class asso ciations to b e made while providing single
sub classing This is to o restrictive for many practical purp oses Consider the sp eci cation of a
printer a fax machine a copier and an all in one machine The rst three devices knowhowto
print fax or copy a do cument while the last device combines the prop erties of the three Since
the metho ds for printing copying and faxing are the same for the corresp onding devices and the
all in one machine it is desirable to reuse the functions written for the typ e of the latter The
following is the required sp eci cation
type T Printer
print T Document implementation
type T Copier
copy T Document implementation
type T Fax
fax T Document implementation
type T AllInOne subtype of T Printer T Copier T Fax
AllInOne inherits b oth the b ehavior sp eci cations and their implemen In this example the typ e T
tations from its three parenttyp es Such an arrangementwould b e imp ossible in Java and all the
co de would have to b e rep eated twice
What do es it mean for a function to b e inherited It means that the function co de can not
only b e used in the typ e it is sp eci ed on but also in subtyp es that do not override the b ehavior
asso ciation for that function The following example illustrates this p oint another example of co de
inheritance was given in Section
type T Account
withdraw T Amount amount implementation a
type T ChequingAccount subtype of T Account
type T RRSPAccount subtype of T Account
withdraw T Amount amount implementation b
T Account anAccount
T ChequingAccount aChequingAccount
T RRSPAccount anRRSPAccount
anAccount withdraw
aChequingAccount withdraw
anRRSPAccount withdraw
A generic account allows a p erson to withdraw money and provides an implementation function a
for the b ehavior withdraw The same implementation can b e used for chequing accounts since
the withdrawal pro cedure is the same However registered retirementsavings plan accounts have
a totally di erent withdrawal pro cedure implemented by the function b Therefore the b ehavior
applications and will dispatch to function a while the b ehavior application will dispatchto
function b The same co de is used for typ es T Account and T ChequingAccount
Dispatch
The pro cess of cho osing the function to execute according to the receiver typ e is called dispatch In
the presented typ e system multiple dispatch Section is adopted
Multiple dispatch is a complicated pro cess The description of dispatch algorithms used for
multiple dispatch is outside the scop e of this dissertation Some of the prop osed algorithms can b e
found in DCG DGC CTK CT and DAS However in a typ echecked program
dispatch should never end with a metho d not understo o d or message ambiguous error The
conditions that the sp eci cations are required to meet in order to provide such an assurance are
outlined b elow
Some terminology rst The asso ciation of the form
behavior product type implementation function
de nes that a function function is asso ciated with the b ehavior behavior on typ es that par
ticipate in the product type For example the following
compare T Point T Point implementation fun point point
return point x point x and point y point y
denotes asso ciation b etween the b ehavior compare and the function given on the pro duct typ e
hT Point T Pointi In other words it is assumed that if two p oints are arguments to the b ehavior
application of compare the ab ove function should execute
A b ehavior can haveseveral asso ciations for di erent argumenttyp es In the presented system it
is required that the pro duct typ es that participate in the asso ciations b e di erent up to parametric
typ e families In other words the following asso ciations can co exist
isEmpty T List X implementation function
isEmpty T Set X implementation function
while the following ones can not
isEmpty T List Person implementation function
isEmpty T List String implementation function
since in the second case the argumenttyp es are from the same parametric family T List and are
not distinct enough
The reason for the ab ove restriction is the multi fold increase in dispatch complexity in case the
restriction is lifted This is due to the necessity to dispatch di erently on typ es from the same
parametric family in the absence of the ab ove restriction Multi metho d dispatch itself is quite
complicated and complicating it even further do es not seem to provide any additional mo deling
power For example the ab ove situation can b e resolved in the following manner
type T SpecialPersonList subtype of T List T Person
isEmpty T Boolean implementation function
type T SpecialStringList subtype of T List T String
isEmpty T Boolean implementation function
or by using classes
class C PersonList implements T List T Person
isEmpty implementation function
class C StringList implements T List T Person
isEmpty implementation function
If P is a pro duct typ e of a b ehavior argumentinabehavior application behavior args then
only certain asso ciations will b e relevant An asso ciation
behavior product type implementation function
is called applicable to an argument product type P i P product type Ofthetwo asso ciations
and applicable to P is called morespeci c than for an argument type P i the pro duct typ e
sp eci ed in the asso ciation is a subtyp e of the pro duct typ e of the b ehavior asso ciation
A b ehavior is always dispatched according to the most speci c asso ciation for a given argument
pro duct typ e P Therefore the typ e system has to verify that for every typ e correct b ehavior
application behavior args for every P suchthatP static typ e of args andalltyp es in P
are class typ es the set of the most sp eci c applicable asso ciations has exactly one element
If the set is empty it means that there are no functions that the system should execute during
b ehavior application the situation usually referred to as a message not understo o d error On
the other hand several most sp eci c elements mean that the system can not cho ose which function
to execute message ambiguous error
The requirement that all typ es in P must b e class typ es is due to the fact that ob jects can only
exist inside classes Therefore any set of arguments that app ears during dynamic execution of the
program has a typ e P such that all typ es in P are class typ es
The following example illustrates the discussion ab ove
The typ e system of ML BM a whichisinmanyways similar to the one presented here has a similar restriction
T_Shape
T_Rectangle T_Circle
T_Point
implements
C_Point
extends
C_Rectangle C_Circle
Figure Shap e typ e hierarchy
type T Shape
center T Point
intersects T Shape T Boolean
type T Rectangle subtype of T Shape
height T Real
width T Real
intersects T Rectangle T Boolean implementation functionRR RR
intersects T Circle T Boolean implementation functionRC RC
class C Rectangle extends C Point implements T Rectangle
type T Circle subtype of T Shape
radius T Real
intersects T Circle T Boolean implementation functionCC CC
intersects T Rectangle T Boolean implementation functionCR CR
class C Circle extends C Point implements T Circle
type T Point subtype of T Circle T Rectangle
intersects T Point T Boolean implementation functionPP PP
class C Point implements T Point
The sp eci cation de nes a hierarchyofshapetyp es and implements a set of intersection functions
The typ e T Shape is an abstract typ e there is no class implementing shap es Typ es T Rectangle
Circle and T Point are concrete typ es The typ e structure for this example is depicted in T
Figure
Consider the following b ehavior application intersects aPoint aPoint The set of ap
plicable asso ciations include the asso ciations RR CC andPP ofwhich the third one is the most
sp eci c
arguments h C Point C Pointi hT Rectangle T Rectanglei RR
arguments hC Point C Pointi hT Circle T Circlei CC
arguments hC Point C Pointi hT Point T Pointi PP
PP hT Point T Pointi hT Rectangle T Rectanglei RR
PP h T Point T Pointi hT Circle T Circlei CC
Therefore the function functionPP will b e executed If the asso ciation PP was removed the set
of applicable asso ciations would consist of RR and CC noneofwhich is more sp eci c than the other
and the b ehavior application would b e ambiguous
Assume that the asso ciation CR is removed Then the application intersects aCircle
aRectangle would not haveany applicable asso ciations even though the application is statically
typ e correct
Note however that the absence of applicable asso ciations for the argumenttyp e hT Shape
T Shapei do es not cause problems since the typ e T Shape is abstract and therefore the argument
Shape T Shapei can never b e an actual argumenttyp e for a b ehavior application typ ed h T
The algorithms for verifying the restrictions describ ed ab ove will b e intro duced in Chapter
and their formal treatment is in Chapter
In this section the dispatch pro cess and the requirements related to its consistency havebeen
discussed Next higher order functional constructs and their typing will b e considered
Closures and typeif
Behavior application is a p owerful construct that allows a programmer to conveniently express most
of the necessary computations Sometimes however a function needs to b e intro duced for a single
computation only In such cases creation of a b ehavior and binding it to the necessary function
is to o exp ensive to b e tolerated Another more concise construct called a closure provides the
capability to construct such one use only functions on the y
Consider the following sp eci cation of a b ehavior map that applies the given argument b ehavior
to all elements of the receiver set and pro duces a set of answers
type T Set X
map X Y T Set Y
Assume the programmer wants to use this b ehavior to pro duce a set that consists of all elements of
the receiver set of numb ers increased by The following co de is supp osed to p erform the task
T Set T Number aSourceSet aDestSet
aDestSet aSourceSet map
but which b ehavior should b e put in the place of The b ehavior should takea number and
pro duce that numb er increased by While it is p ossible to de ne a new b ehavior for that purp ose
type T Number
add T Number implementation return add
aDestSet aSourceSet map add
such a de nition is unnecessary since it is only used once
With closures the ab ove example can b e co ded as
aDestSet aSourceSet map fun x return x add
where the anonymous function was intro duced on the y This style of programming is common
in functional languages however it is rarely used in statically typ ed ob ject oriented programming
languages The presented typ e system not only allows the ab ove example to b e programmed it also
infers the typ e of the function from the co de of the function In the example ab ove the typ e inferred
will b e T Number T Number provided that the typ e of the b ehavior add is T Number T Number
Closures allow simpli ed sp eci cation of functions that work the same way on ob jects of all typ es
they are applicable to What happ ens if a b ehavior that is used only once has to b ehave di erently
on di erenttyp es of arguments In this case a sp ecial construct typeif can b e utilized
Consider the following situation there is a set of p ersons and the task is to print out the names
of the p ersons in the set However if a p erson from the set happ ens to b e a student the studentid
numb er has to b e printed as well
It is p ossible to de ne a new b ehavior extendedName and implement it di erently for p ersons
and students
type T Set X
foreach X T Unit
type T Person
name T String
extendedName T String implementation
return name
type T Student subtype of T Person
studentId T Natural
extendedName T String implementation
return name student ID studentId convertToString
T Set T Person aSet
let f fun x x extendedName print in aSet foreach f
However this approach su ers from the same drawback as the rst approach used to implement the
previous example Namely theintro duction of a new b ehavior that is only going to b e used once is
unwarranted
Using the typeif construct the ab ove example can b e rewritten as
T Set T Person aSet
let f fun x
x name print
typeif x is T Student then
studentID print
x studentId print
in aSet foreach f
The typeif construct checks if the run time typ e of the given expression is a subtype of the given
typ e and executes the co de given if it is The co de is typ echecked with the assumption that the
expression is of the typ e given This sp ecial b ehavior of the typeif construct with resp ect to typ e
checking is crucial for static typ e safety The example ab ovewould not typ echeck if the typ echecker
After certain simpli cations
did not take the given typ e T Student into account as otherwise the typ e of x would b e considered
to b e T Person and the b ehavior application x studentId would b e considered illegal
The same construct can b e used to co de the BROWSER test from Section
T Object root
typeif root is T Number then
root print
elseif root is T Person then
root age print
else
Something else print
Note the usage of else and elseif in the ab ove example
In this section closures and the typeif constructs have b een considered Their use was illustrated
byseveral examples and the issues of their typing were discussed
This concludes the overview of the intermediate abstraction layer consisting of typ es and func
tions In the next section the lowest sp eci cation layer will b e describ ed
Implementation typ es
Implementation typ es and functions representthelowest layer of the presented typ e system They
are designed to provide supp ort for interop erability and low level optimizations
Implementation functions represent what is sometimes referred to as foreign or primitive func
tions i e functions that are sp eci ed outside of the system Implementation types on the other
hand serve dual purp ose they provide a low level structure sp eci cation and they allow for a limited
form of typ echecking of the foreign function interfaces
The way implementation typ es and functions are describ ed is implementation dep endent For ex
ample if the target language is C implementation functions are C functions while implemen
tation typ es are C classes If a target language provides a notion of subtyping implementation
typ es mayhave a subtyping relationship b etween each other otherwise they are unrelated
Implementation typ es can b e used to implement the structure de ned by classes For example
the following is the sp eci cation of integers and reals under the assumption that the target language
is C
type T Real
add T Real T Real
infinite class C Real implements T Real
implementation type short atomic float
add C Real C Real implementation function
float addRR float self float arg return self arg
add C Integer C Real implementation function
float addRI float self int arg return self arg
type T Integer
add T Integer T Integer
infinite class C Integer implements T Integer
implementation type short atomic int
add C Integer C Integer implementation function
int addII int self int arg return self arg
add C Real C Real implementation function
float addIR int self float arg return self arg
Note that the sp eci cation ab ove requires classes rather than typ es in argument sp eci cations
The reason for that is the fact that the system has to knowhow to convert ob jects into low level
data and that information is only provided by classes
The system veri es that all p ossible b ehavior applications can b e dispatched to an appropriate
function or implementation function In the ab ove sp eci cation all four combinations had to b e
explicitly sp eci ed since C can not dispatch on the data of typ e int The system also makes
sure that substitutability for sub classes is not violated in case the sub class uses an implementation
typ e that is di erent from the one used in the sup erclass
The usage of implementation typ es allows seamless integration of foreign data into the existing
system Once an implementationtyp e and a class that describ e the foreign ob jects are sp eci ed those
ob jects can b e manipulated bybehaviors and functions in exactly the same manner as the ob jects
native to the system All co de previously written will work on foreign data with no mo di cations
Another use of implementation typ es and functions is related to the sp eci cation of so called
primitive types Unlike other systems the system describ ed here is extensible in that new primitive
typ es can b e easily intro duced The ab ove example can b e seen as a de nition of integer and real
primitivetyp es that is done by a programmer rather than by the programming language designer
The interop erability and extensibilityprovided by this system are extremely imp ortant for
database applications that tend to evolveover long p erio ds of time and incorp orate data from dif
ferent sources some of which are b eyond the database designer s control Other arguments in favor
of implementation typ es and functions as wellasinfavor of the three layer typ e system structure
in general can b e found in LOS
An ordinary user may never see or use implementationtyp es and functions This low level
mechanism is provided for administrative purp oses and is not supp osed to b e used by the ordinary
users
While implementation typ es and functions are imp ortantforinterop erability their role in typ e
checking which is the ma jor topic of the presented research is marginal Implementation typ es
and functions describ ed here will not b e considered in any detail in the following chapters that are
devoted primarily to typ echecking
The next section describ es the advantages of the three layer design and its p ossible applications
in a database system
Three layer design Advantages and applications
The three layer design describ ed in this chapter not only allows for a high degree of co de reuse but
also makes the system more transparent for the user by making it p ossible to use the system at
di erent abstraction layers dep ending on the user s needs and level of exp ertise
An ordinary user p osing queries against the database using a query language only needs to know
ab out the highest abstraction layer that of b ehaviors and typ es A query maycontain b ehavior
applications a k a path expressions and the knowledge of the typ es and b ehaviors de ned in the
system is su cient for the purp ose of constructing such b ehavior applications Thus an ordinary user
is completely shielded from any implementation details suchasthelayout of the ob jects involved in
the query and the waybehaviors are implemented This has twomajoradvantages rst the user is
presented with a signi cantly simpli ed yet consistent view of the ob ject mo del Second the user is
provided with a uniform view of ob jects and b ehaviors that is indep endent of their implementation
For example if a p ointtyp e is implemented via two di erent classes p olar and rectangular p oints
the path expression
aPoint x
will pro duce the x co ordinate for b oth p olar and rectangular p oints even though the co de that is
executed in b oth cases is completely di erent
The meaning of the sp eci er short atomic is explained in Section B
An application programmer should b e given access to the second abstraction layer consisting of
functions and classes This arrangementwould make it p ossible to implement a new functionality
by writing function co de and new data structures by de ning new classes Thus an application
programmer is given the opp ortunitytodevelop the system However an application programmer
is shielded from the di erences in the op erating system functionality and bit level data structures
that may exist b etween di erent systems as this functionalityisprovided by implementation typ es
and functions that are not visible at the second abstraction layer The co de develop ed at this
abstraction layer is therefore system indep endent and p ortable In addition to this if a piece of
co de in an existing system is mo di ed e g a more e cient implementation of a particular b ehavior
is pro duced such mo di cation do es not a ect the validity of the user co de written at the rst
abstraction layer as the interfaces are not a ected
Finally a database designer would have access to the third abstraction layer implementation
typ es and functions Using this layer involves dealing with native co de which makes it p ossible
to handle tasks involving low level system access access to foreign data and intro duction of new
optimized primitivetyp es e g multimedia typ es such as audio and video It should b e noted that
any developmentdoneatthislayer do es not a ect the validity of the co de written earlier by either
ordinary users or application programmers
The basic typ e system
This section describ es an application of the principles and constructs describ ed in this chapter The
basic typ e system for the TIGUKATobjectmodel Pet has b een develop ed as a pro of of concept
and the basis for the development of the TIGUKAT programming language
Only ob ject typ es atomic typ es and container typ es will b e describ ed here The complete sp eci
cation of the basic TIGUKATtyp e system including re exive metaclass and metatyp e sp eci cations
can b e found in App endix A
Ob ject typ es
In the presented typ e system all typ es can b e separated into three basic categories object types
function types andproduct types The typ es from di erent categories do not haveany subtyping
relationships with each other This structure is depicted in Figure The typ es and are
purely theoretical concepts they can not b e used by the user in anyway In fact the typ e can b e
understo o d as a typ e of all typ e errors that are guaranteed not to o ccur in a successfully typ echecked
program
T_Unit Object type hierarchy Behavior type hierarchy Product type hierarchies
Figure TIGUKATtyp es
Object types are the typ es of all ob jects in the system except for functions b ehaviors and
pro ducts This is the typ e category that includes almost all user and system de ned typ es in the
system This category will b e discussed in detail later
Product types are typ es of products that are ordered tuples of values Subtyping b etween pro duct
typ es is induced by the subtyping b etween their comp onenttyp es n ary pro duct typ es are de ned
for all n greater than Pro duct typ es of di erent aritydonothaveany subtyping relationship
with each other Thus there are several unrelated pro duct typ e hierarchies one for each n A
sp ecial typ e T Unit plays the role of a ary pro duct it has no subtyp es or sup ertyp es It is used
primarily for sp ecifying return typ es of b ehaviors that are not supp osed to return a result n ary
pro ducts are assumed to have the following de nitions
type T ProductN covar X covar X covar XN
project X
project X
projectN XN
for each N greater than
Function and behavior types are de ned as follows
type T Function contravar A covar R
type T Behavior contravar A covar R subtype of T Function A R
These are the only functional typ es in the system
In the ob ject typ e hierarchy there are twotyp es that play a sp ecial role They are T Object and
T Null
The typ e T Object is a common sup ertyp e of all ob ject typ es It do es not de ne any b ehaviors
but they can b e added to T Object by the user
The typ e T Null is a common subtype of all ob ject typ es Therefore values of typ e T Null can
b e used everywhere in the program The values of typ e T Null denote uninitialized missing or
otherwise absent null values Thus T Null is a concrete typ e
Figure depicts the relative placementofvarious ob ject typ es in the ob ject typ e hierarchy
T_Object
Container type hierarchy Class type hierarchy Metatype hierarchy Atomic type hierarchy
T_Null
Figure TIGUKAT ob ject typ es
Even though there is no common sup ertyp e of al l typ es in the system T Object is a common
sup ertyp e of object types but not al l types the parametric nature of the typ e system allows for sp ec
i cation of b ehaviors that are uniformly applicable to al l ob jects including pro ducts and b ehaviors
The following is the sp eci cation of these b ehaviors
behavior OIDequal X X T Boolean Object identity equality
behavior equal X X T Boolean Equality
Shortcut operator binary
implementation fun x y return x OIDequal y
notEqual X X T Boolean Inequality
Shortcut operator binary
implementation fun x y return not x y
print X OutputStream X Print to an output stream
apply X Y Y Behavior application
Shortcut operator binary
Due to the fact that in the presented system the notations f a b and a f b are equivalentand
interchangeable the ab ove co de for equality and inequalityistyp e correct and b ehaves as exp ected
The following is the sp eci cation of the two sp ecial ob ject typ es
type T Object
type T Null subtype of all object types
class C Null implements T Null
Atomic typ es
Atomic typ es include the standard set of real integer and natural numb ers characters and b o oleans
Numeric T PartiallyOrdered T Ordered and T Discrete abstract out several Abstract typ es T
common prop erties that are likely to b e reused for future extensions
T_PartiallyOrdered(T_Numeric) T_Boolean
T_Ordered(T_Numeric)
T_PartiallyOrdered(T_Character) T_Numeric
T_Ordered(T_Character) T_Discrete T_Real
T_Character T_Integer
T_Natural
Figure TIGUKAT atomic typ es
type T Discrete subtype of T Object
pred selftype Return the previous element
succ selftype Return the next element
type T PartiallyOrdered contravar X subtype of T Object
less selftype T Boolean Antisymmetric comparison
Shortcut operator binary
greater selftype T Boolean Antisymmetric comparison
Shortcut operator binary
implementation fun x return x self
lessOrEqual selftype T Boolean Symmetric comparison
Shortcut operator binary
implementation fun x return x self or x self
greaterOrEqual selftype T Boolean Symmetric comparison
Shortcut operator binary
implementation fun x return x self
type T Ordered contravar X subtype of T PartiallyOrdered X
max selftype selftype Maximum of the two
implementation fun x
return if x self then self else x endif
min selftype selftype Minimum of the two
implementation fun x
return if x self then x else self endif
type T Numeric subtype of T Ordered T Numeric
abs T Numeric Absolute value
negate T Numeric Negation
Shortcut operator unary
add T Numeric T Numeric Addition
Shortcut operator binary
subtract T Numeric T Numeric Subtraction
Shortcut operator binary
multiply T Numeric T Numeric Multiplication
Shortcut operator binary
divide T Numeric T Numeric Division
Shortcut operator binary
So far only abstract typ es have b een sp eci ed Note how F b ounded quanti cation CCH
Section is used in ordered typ e sp eci cations to disallowunwanted cross comparisons such
as comparisons b etween characters and numb ers The sp eci cation of ordered typ es also provides a
default implementation for all b ehaviors except for less Once the implementation of that b ehavior
is provided all the other comparison b ehaviors are automatically available
type T Boolean
not T Boolean Negation
or T Boolean T Boolean Logical OR
Shortcut operator binary or
and T Boolean T Boolean Logical AND
Shortcut operator binary and
xor T Boolean T Boolean Logical XOR
Shortcut operator binary xor
if X X X If expression Shortcut
if then else endif
finite class C Boolean implements T Boolean
implementation type short atomic int
not implementation function
not int self return self
or C Boolean implementation function
and int self int x return self x
type T Character subtype of T Discrete T Ordered T Character
ord T Natural Returns the ordinal value
finite class C ASCIICharacter implements T Character
implementation type short atomic char
finite class C UnicodeCharacter implements T Character
implementation type short atomic Unichar
The ab ovetyp es are concrete All of the describ ed classes are finite since they do not allowobject
creation yet maintain their nite extents The parameterized b ehavior if de ned on b o oleans
is typ ed in suchawayastoprovide the most static typ e information p ossible it is equivalent
to if X Y lub X Y There are two separate classes implementing characters a standard
ASCI I character and a Unico de character Since these are classes rather than types any program
written will b e able to work seamlessly with b oth typ es of characters or any mix of them
type T Real subtype of T Numeric
truncate T Integer Truncate throwing away
the fractional part
round T Integer Round to the nearest
sign T Integer Sign if positive if
negative otherwise
Refined from T Numeric
abs T Real
negate T Real
add T Real T Real
subtract T Real T Real
multiply T Real T Real
divide T Real T Real
infinite class C Real implements T Real
implementation type short atomic float
infinite class C LongReal implements T Real
implementation type long atomic double
type T Integer subtype of T Real T Discrete
div T Integer T Integer Integer division
Refined from T Real
abs T Natural
negate T Integer
add T Integer T Integer
subtract T Integer T Integer
multiply T Integer T Integer
infinite class C Integer implements T Integer
implementation type short atomic int
infinite class C LongInteger implements T Integer
implementation type long atomic long int
type T Natural subtype of T Integer
mod T Natural T Natural Remainder
Refined from T Integer
truncate T Natural
round T Natural
sign T Natural
div T Natural T Natural
add T Natural T Natural
multiply T Natural T Natural
infinite class C Natural implements T Natural
implementation type short atomic unsigned
infinite class C LongNatural implements T Natural
implementation type long atomic long unsigned
The ab ove is the sp eci cation of numeric typ es Eachofthetyp es is implemented byseveral classes
all classes are infinite as they have in nite extents and do not allow ob ject creation Careful
rede nition of binary metho ds along the typ e hierarchy allows for a very precise typing For example
the system will deduce that has the typ e T Natural while has the typ e T Real
Anytwonumerics can b e compared using comparison op erations including p ossible min and max
Numeric and therefore T Ordered T Numeric op erations since all numeric typ es are subtyp es of T
Integers are also discrete subtyp e of T Discrete and therefore the b ehaviors pred and succ can
b e applied to them
Collection typ es
The collection typ e hierarchy is represented here only partially Its full description can b e found in
App endix A The hierarchy describ ed here is depicted in Figure
type T Collection covar X
hasElement X T Boolean Checks if the element
is in the collection
cardinality T Natural Cardinality of the collection
pick X Pick an element
map X Y T Collection Y Apply the given function to all
elements and return the
collection of results
filter X T Boolean T Collection X Filters the receiver
collection using the
argument function as a filter T_Collection(X)
T_Set(X) T_List(X)
all X all X X=T_Character
T_EmptySet T_Array(X) T_EmptyList T_String
Figure TIGUKAT collection typ es
sort where X subtype of T Ordered X T List X Sorts the
elements of the collection
Only applicable to
collections of ordered elements
sort X X T Boolean T List X Sorts the collection using
the supplied sorting function
type T Set covar X subtype of T Collection X
subset T Set Y T Boolean Is the receiver
a subset of the argument
union T Set Y T Set lub X Y Set union
intersect T Set Y T Set glb X Y Set intersection
difference T Set Y T Set X Set difference
addElement Y T Set lub X Y Add an element
removeElement Y T Set X Remove an element
Refined from T Collection
map X Y T Set Y
filter X T Boolean T Set X
infinite class C Set X implements T Set X
const T List X list
type T EmptySet subtype of T Set X
finite class C EmptySet implements T EmptySet
type T List covar X subtype of T Collection X
at T Natural X Get at arg s position
cat T List Y T List lub X Y Concatenation
slice T Natural T Natural T List X Slice from i th
to j th element
Refined from T Collection
map X Y T List Y
filter X T Boolean T List X
infinite class C List X implements T List X
type T EmptyList subtype of T List X
finite class C EmptyList implements T EmptyList
type T Array novar X subtype of T List X
at T Natural X Set at arg s position
slice T Natural T Natural T List X Slice set
manual class C Array X implements T Array X
type T String subtype of T List T Character
Refined from T List
cat T String T String
slice T Natural T Natural T String
filter T Character T Boolean T String
infinite class C String implements T String
infinite class C UnicodeString implements T String
This sp eci cation de nes several immutable parameterized collection typ es and a mutable typ e
T Array The typ e of empty sets lists is a subtyp e of all set list typ es so that a single empty
set list can b e used in all set list op erations The typ e T String is de ned as a subtyp e of the
character list typ e that has some additional prop erties
The set theoretic and higher order map lter sort b ehaviors de ned on collections have precise
typings This prop erty can b e used to de ne a statically typ echecked version of a query language
over immutable sets
The slice assignment de ned on arrays allows one to write the following co de
T Array T Number arr
arr slice Assign to elements and
Note that the class that implements arrays is sp eci ed as manual Itallows creation of new arrays
but do es not maintain the set of all arrays created so far as that would b e very exp ensive
Note also that the class of sets uses T List for implementation of sets The ability to sp ecify
relationships like this is a consequence of the separation b etween interface and implementation in
the presented typ e system
This concludes the overview of the basic TIGUKATtyp e system that was presented as an
example of the application of the presented typ e system to an ob ject oriented ob ject mo del The
resulting basic typ e system provides precise typing for many traditionally problematic areas of ob ject
oriented sp eci cation covariant arguments query typing parametricity and binary metho ds Yet
the resulting system is statically typ e safe and has the substitutability prop erty
Conclusions
In this chapter an overview of the prop osed typ e system has b een presented Three layers of
sp eci cation typ es and b ehaviors classes and functions implementation typ es and functions have
b een considered Their use was exempli ed with a numb er of examples In the pro cess it has b een
shown that the presented typ e system can successfully deal with all the tests describ ed in Section
Finally an example application of the develop ed principles to the TIGUKAT ob ject mo del has b een
describ ed
In the next chapter the typ echecking algorithm will b e describ ed The theorems and pro ofs of
its correctness and termination will b e considered in Chapter
Chapter
The Language and Typ echecking
One of the most imp ortant constituent parts of anytyp e system is its typechecking algorithm The
typ echecking algorithm allows a translator to verify that the program conforms to the given sp ec
i cations and issue an error message if it do es not A veri able typ e system has a typ echecking
algorithm that is guaranteed to terminate even if a program b eing checked contains typ e errors
On the other hand a sound typ e system has the prop erty that once a program successfully passes
through a typ echecker it is guaranteed not to pro duce anytyp e errors at run time
The typ e system presented here is b oth veri able and sound These prop erties will b e proven in
Chapter on the basis of the typ echecking algorithm presented in this chapter
This chapter serves to describ e two imp ortant parts of the typ e system the typ echecking al
gorithm Section that works on a simpli ed version of the language the target language
Section and the de sugaring translation pro cess Section that pro duces a program in
the target language from a given source language program
The heart of the typ echecking algorithm is the algorithm that decides entailment Section
This algorithm is language indep endent and is part of the typ e system core
In the next section b oth source and target languages will b e considered and the translation
pro cess will b e describ ed
Syntax and translation
Since the b eginning of the computer era there has b een a gap b etween an e cient and human
readable presentation of information The rst form of information presentation is easily pro cessed
by the computers on the other hand the second form is advantageous to human b eings The use
of computers to automate the transformation b etween the two forms of information representation
has b een a cornerstone of the computer revolution
In this section the source and target Section languages will b e describ ed The source
language has a traditional syntax which is familiar to p eople who deal with pro cedural and ob ject
oriented programming The target language s syntax is less standard however it is much more
concise and signi cantly more convenient to use in automatic typ echecking
Note that this chapter do es not present a complete source language design Rather it is a pro of
of concept design that shows how the presented typ e system can b e used to mo del various features
existing in to day s programming languages
Finally in Section the pro cess of automatic translation from source to target language will
b e describ ed The translation pro cess is sometimes called de sugaring since it removes syntactic
sugar from the program making it more suitable for further automatic pro cessing
The target language
The target language is a de sugared simpli ed ob ject oriented language that will b e used for typ e
checking It consists of typ e and subtyp e de nitions b ehavior declarations and function asso cia
tions Class sp eci cations are translated to typ e de nitions by the pro cess describ ed in Section
A program in the target language consists of typ e de nitions subtyp e de nitions b ehavior de
nitions asso ciations and an expression
program defs expr
defs def def
def type def subtype def constant def
behavior def association
Typ e de nitions describ e typ es variance of their parameters and validity conditions They also
sp ecify whether a typ e is concrete or abstract
type def concrete spec type constraints
name type par specs
concrete spec concrete
type par specs type par spec type par spec
type par spec variance name
variance covar contravar novar
constraints constraint constraint
constraint type type
The following are examples of typ e sp eci cations
type T Number
concrete type T Behavior contravar Arg covar Result
concrete type T Product covar X covar X
concrete type T Set covar X
concrete type X T Ordered X T OrderedSet covar X
Atyp e can b e de ned only once It is illegal to havetwo de nitions of the same typ e typ e
with the same name
Typ es that are used in sp eci cations are de ned as follows
type name types
glb types
lub types
types type type
type proper name names
names name name
Examples of typ es are
T Number
T Behavior T Product T Set X T Set Y T Set lub X Y
T Dictionary X T Dictionary T Number X
The shortcut typeA typeR will b e used for T Function typeA typeR
functional typ es and the shortcut type typeN will be used for
T ProductN type typeN pro duct typ es It will also b e assumed that
type type unary pro ducts and typ es are indistinguishable
In the following presentation the concept of freetype variables will b e extensively used The
set of free typ e variables in a typ e expression is de ned as a set of name s in that expression
minus the set of all name s de ned in typ e de nitions and is denoted as FTV t For example
the set of free typ e variables of the expression T Set X T Set Y T Set lub X Y
is fX Yg Atyp e expression that has an empty set of free typ e variables will b e called a closed
Number type e g T
Subtyp e de nitions de ne subtyping relationships b etween typ es A subtyp e de nition has the
form
subtype def
constraints simple type simple type
simple type name types
simple types simple type simple type
The requirement that only simple typ es can o ccur in subtyp e de nitions is designed to protect
against user de ned subtyping of upp er and lower b ound typ es It is also assumed that no
subtyp e de nitions involve T Function T Behavior and T Product at the outermost level
i e that the user is not allowed to de ne any additional subtyping relationships for these typ es
Syntactically valid examples of subtyp e de nitions are
T Real T Number
X T Ordered X T Set X T Ordered T Set X
Constant de nitions are used to declare constants and their typ es
constant def const type name
Examples of constant de nitions are
const T Class T Person C Person
const T Integer nargs
A constant can b e de ned only once It is illegal to havetwo de nitions of the same constant
The type of a constant should b e a closed one
Behavior de nitions are used to declare b ehaviors to b e used in the program They sp ecify
argument and result typ es of a b ehavior as well as validity conditions
behavior def behavior def proper
behavior def proper
behavior constraints type type name
The typ e on the left hand side of should not contain typ e op erators lub and glb Examples
of b ehavior de nitions are
behavior T Number T Number add
behavior X T PartiallyOrdered X T Set X T Set X maximals
There can b e several de nitions of the same b ehavior For example the following de nitions
can app ear in the same program
behavior T Number T Number T Number add
behavior T Real T Real T Real add
behavior T Integer T Integer T Integer add
behavior T Natural T Natural T Natural add
This last prop erty is the reason whybehavior and constant de nitions are separated from each
other While duplicate constant de nitions are disallowed duplicate b ehavior de nitions are
p ossible and the system is resp onsible for checking their consistency and nding out the most
sp eci c typ e for eachbehavior
Asso ciations are used to asso ciate an expression to a b ehavior on a set of typ es The asso ciations
thus provide a link b etween a b ehavior sp eci cation and its implementation
association behavior def proper abstraction expr
behavior def proper primitive name
The di erence b etween asso ciations and b ehavior de nitions is analogous to the di erence
between abstract and concrete typ es However the former is much more relevant to the
typ echecking than the latter The primitive asso ciations are provided as a to ol that enables the
language designer to provide the primitive low level function de nitions to base the language
up on These functions corresp ond to implementation functions of the source language The
conditions that the primitives must satisfy for the typ e system to b e sound are outlined in
Section
Expressions constitute the action part of a program There are several kinds of expressions
describ ed b elow
expr name
product expr
projection expr
let expr
compound expr
application expr
abstraction expr
Pro duct expressions are used to group several ob jects into one Pro duct expressions are
primarily used to bypass the single argument restriction for b ehaviors and abstractions
product expr expr expr
expr expr
A pro duct expression with a single comp onentisequivalent to that comp onent For
example a b is a binary pro duct expression while a is a unary pro duct expression
equivalentto a
Pro jection expressions are used to extract comp onents from pro duct expressions These
expressions are not primitive rather they are understo o d as a shortcut for pro jection
b ehavior applications
projection expr expr number
number
For example a b b while a b is illegal An expression expr number is
treated as project number expr where pro jection b ehaviors are de ned as follows
behavior project X Xn X For all n
behavior project X Xn X For all n
behavior projectN X Xn XN For all n N
Let expressions make it p ossible to intro duce a new name in the environment Both typ ed
and untyp ed variants are allowed if a variable is untyp ed its typ e is inferred from the
context
let expr let type name expr in expr
type must b e a closed typ e An abbreviation with multiple bindings will b e used to
denote a sequence of nested let expressions For example
let a f x b g x in a b
is equivalentto
let a f x in let b g x in a b
Comp ound expressions are used to compute expressions in sequence discarding the results
of all but the last one
compound expr expr expr
For example the result of a b c is c
Abstractions are anonymous functions abstractions They construct closures that can
b e executed immediately or later on
abstraction expr fun names
expr return expr
For example
fun x return add x
is an abstraction that creates a closure that will b e able to add to its argumentand
return the result Note that there is always a single argument whichmayormaynotbe
a pro duct The keyword return is used to sp ecify the fact that something is returned
from the function If it is absent the function is presumed to implicitly return a sp ecial
Unit ob ject unit of typ e T
Applications are b ehavior and abstraction applications to a given argument They are de
noted by juxtap osition and asso ciate to the left
application expr expr expr
For example fabis equivalentto f a b Note that the last expression makes use
of unary pro ducts of the form x Multi argument function and b ehavior applications
can b e similarly expressed via n ary pro duct expressions add a b
In this section the target language has b een describ ed The target language is designed to b e
an intermediate language that has a form convenientfortyp e checking In the next section the
translations of various features of the source language into the target language will b e describ ed
The translation
The source language has b een informallyintro duced in Chapter This section describ es a transla
tion of the source language into the target language describ ed in the previous section
Typ e sp eci cations in the source language de ne typ es their subtyping relationships b ehaviors
applicable to the ob jects of these typ es and b ehavior to function asso ciations The following
is the description of the translation pro cess for the typ e sp eci cations of the source language
whose syntax is given b elow
type def type type def proper
where constraints
subtype of type spec list
behavior def list
type def proper
type name type par spec type par spec
type par spec covar contravar novar name
Explicit receiver Every b ehavior sp eci cation for the typ e is transformed into a stand
alone b ehavior de nition by adding the receiver as an explicit rst argument The added
argumentisgiven the typ e b eing de ned if selftype is not used anywhere in the b e
havior sp eci cation Otherwise selftype is replaced byafreshtyp e variable S and the
constraint S subtype of type being defined is added to the where clause of the
b ehavior sp eci cation Example
type T Set covar X
union selftype selftype
pick X
is transformed into
type T Set covar X
union S S S where S subtype of T Set X
pick T Set X X
Note how the explicit rst argumenttyping dep ends on the presence or absence of
selftype
Assignment elimination For all b ehavior de nitions that use the symbol the b ehavior
de nition is split into two one identical to the original but with symbol in place of
and the other with the name obtained from the original one by app ending the pre x set
Unit Behavior the additional argument of the return typ e and the new return typ e T
de nitions that use the symbol get transformed into the second alternative outlined
ab ove For example
age T Person T Natural
put T OutputStream X X
substr T String T Natural T Natural T String
gets transformed into
age T Person T Natural
set age T Person T Natural T Unit
set put T OutputStream X X T Unit
substr T String T Natural T Natural T String
set substr T String T Natural T Natural T String T Unit
Subtyp e separation Eachtyp e description is split into the typ e sp eci cation prop er and
zero or more subtyp e sp eci cations where clauses related to the typ e b eing de ned stay
with the typ e while where clauses related to a typ e in the appropriate subtype of clause
are kept with the subtyp e sp eci cation that is pro duced from the clause For example
type T OrderedPersonSet covar X where X subtype of T Person
subtype of T Set X
where X subtype of T Ordered X T SpecialSet X
gets transformed into
type T OrderedPersonSet covar X where X subtype of T Person
T OrderedPersonSet X subtype of T Set X
where X subtype of T Ordered X
T OrderedPersonSet X subtype of T SpecialSet X
Type they are not only used for Re exive constants Since typ es are ob jects of typ e T
sp eci cation purp oses but can also b e queried at run time Therefore for eachtyp e
sp eci cation the constant declaration
const T Type name
is added to the program where name is the name of the typ e b eing sp eci ed For
example the typ e sp eci cation
type T Number
results in the addition of the declaration
const T Type T Number
to the program
Syntactic transformations Finally the syntax of the declarations is mo di ed to t the
syntax of the target language Namely
where clauses are transformed into lists of constraints
the b ehavior sp eci cations get transformed from
name arg types res type
into
behavior arg types res type name
b ehaviors with implementation clauses get transformed into asso ciations
For example
type T OrderedPersonSet covar X where X subtype of T Person
T OrderedPersonSet X subtype of T Set X
where X subtype of T Ordered X
T OrderedPersonSet X subtype of T SpecialSet X
union T OrderedPersonSet X
T OrderedPersonSet X T OrderedPersonSet X
add T Integer r T Integer a T Integer implementation
is transformed into
type X T Person T OrderedPersonSet covar X
X T Ordered X T OrderedPersonSet X T Set X
T OrderedPersonSet X T SpecialSet X
behavior T OrderedPersonSet X
T OrderedPersonSet X T OrderedPersonSet X union
association T Integer T Integer T Integer add
fun r a
This concludes the description of the typ e de nition translation
Class sp eci cations in the source language de ne classes their abstract structure elds the
class typ e in nite nite manual or regular sub classing and class extension b ehaviors
de ned on classes and p ossibly their low level structure Syntax of the source language class
de nition is given b elow
class def class specifier class class proper
implements type proper
subclass of classes
extends class ext list
field def list
behavior def list
class specifier infinite finite manual regular
class proper class name name name
class ext list class ext class ext
class ext class spec removing name list
class spec class name class spec class spec
class name name selfclass
classes class proper class proper
Class extension A class extension is a mechanism for textual substitution Therefore cyclic
extension dep endencies b etween classes are not allowed If such a dep endency is detected
it is an error and the translation stops Otherwise classes form a directed acyclic graph
DAG with resp ect to the relationship extends Starting with the ro ots of the DAG
and following the graph edges in the direction opp osite to the one given bytheextends
relationship in suchaway that a no de is visited only when all its parents are visited
width rst traversal the following op eration is p erformed A class that extends an
other class is expanded bycopying all eld and b ehavior de nitions from the class b eing
extended except for the ones whose names are sp eci ed in the appropriate removing
clause marking the copied de nitions in the pro cess Thus inherited de nitions are
marked while native ones are unmarked After the traversal is nished every class that
contains marked de nitions is examined If there are identical de nitions extra copies
are removed if there are con icting de nitions and at least one of them is unmarked
the marked de nitions are removed if there are con icting de nitions and none of them
is unmarked it is an error and the translation stops The de nitions are con icting if
they de ne a b ehavior or eld with the same name If there are con icting unmarked
de nitions for a eld it is also considered an error Finally extends clauses are removed
from all classes
As an example consider the following class sp eci cations
class C Circle implements T Circle
T Point center
T Length majorAxis
center implementation center
majorAxis implementation majorAxis
minorAxis implementation majorAxis
class C Ellipse extends C Circle implements T Ellipse
T Length minorAxis
minorAxis implementation minorAxis
At the rst stage it is determined that there is no cyclic dep endency and C Circle is the
ro ot of the DAG The edge from C Ellipse to C Circle is then traversed and the class
C Ellipse is extended After copying it will take the form
class C Ellipse extends C Circle implements T Ellipse
T Point center
T Length majorAxis
center implementation center
majorAxis implementation majorAxis
minorAxis implementation majorAxis
T Length minorAxis
minorAxis implementation minorAxis
Then since there are two distinct de nitions of the b ehavior minorAxis the marked
inherited one is discarded Finally the extends clause is removed and the resulting
class takes the form
class C Ellipse implements T Ellipse
T Point center
T Length majorAxis
center implementation center
majorAxis implementation majorAxis
T Length minorAxis
minorAxis implementation minorAxis
Note that unmarked native de nitions take precedence over marked inherited de ni
tions Note also that identical de nitions never cause errors even if there are no native
ones additional copies are simply discarded This makes it p ossible to have diamond
shap ed extensions its b ehavior is similar to that of the mechanism of virtual classes in
C Str
Marked inherited de nitions are identi ed by
Field elimination Field de nitions in classes are translated to b ehavior de nitions Before
it is done the check for sub class conformance is p erformed if sub class dep endencies
are cyclic it is an error Otherwise classes form a DAG with resp ect to the relationship
subclass of and for every class there are nitely many sup erclasses in the graph Then
for each class and each sup erclass it is veri ed that if a eld is de ned in a sup erclass its
de nition is either absent from the sub class or has the same typ e or the eld is constant
in the sup erclass and its de nition in the sub class sp eci es a typ e class that is a subtyp e
sub class of the one sp eci ed in the sup erclass This rule is based on the observation
that constant non up datable elds are covariant while up datable elds are novariant
For example the following sp eci cation is legal
type T SmallNatural subtype of T Natural
class C Person
const T Natural age
class C Child subclass of C Person
T SmallNatural age
while the one b elow is not
type T SmallNatural subtype of T Natural
class C Person
T Natural age
class C Child subclass of C Person
T SmallNatural age
After the checkabove has b een successfully p erformed constant eld de nitions of the
form
const type name
are translated into
name type implementation fun x system defined code
Each non constant eld de nition is translated into twobehavior de nitions
name type implementation fun x system defined code
set name type T Unit
implementation fun x y system defined code
The implementation clauses that refer to elds are translated as follows
name implementation field name
is translated into
name field type implementation fun return field name
if field name denotes a constant eld and into
name field type implementation fun return field name
set name field type T Unit
implementation fun x set field name x
if it denotes a non constant eld For example the expanded sp eci cation of C Ellipse
given ab ove will b e translated into
class C Ellipse implements T Ellipse
center T Point implementation system defined
set center T Point T Unit implementation system defined
majorAxis T Length implementation system defined
set majorAxis T Length T Unit implementation system defined
center T Point implementation fun return center
set center T Point T Unit
implementation fun x set center x
majorAxis T Length
implementation fun return majorAxis
set majorAxis T Length T Unit
implementation fun x set majorAxis x
minorAxis T Length implementation system defined
set minorAxis T Length T Unit implementation system defined
minorAxis T Length
implementation fun return minorAxis
set minorAxis T Length T Unit
implementation fun x set minorAxis x
Translation to typ es Up on completion of the class expansion and eld elimination dis
cussed earlier classes are translated into typ es This translation pro ceeds bychanging
the keyword selfclass into selftype changing subclass of and implements clauses
into subtype of clauses and changing each class sp eci er into a type sp eci er Then
the standard typ e sp eci cation translation is p erformed with the following changes
Instead of a type sp eci cation an concrete type sp eci cation is pro duced
The generation of re exiveconstants is done according to the rules b elow rather
than according to the rules sp eci ed for typ e translation
Note that there are no classes in the target language only abstract and concrete typ es
Typ es in the target language that corresp ond to the classes in the source language have
names of the form C X in order to keep names consistent across the two languages This is
done to simplify typ echecking it do es not haveany e ect on the semantics of the notions
of typ e and class For example the class C Ellipse de ned ab ove will b e translated into
concrete type C Ellipse
C Ellipse T Ellipse
association C Ellipse T Point center system defined
association C Ellipse T Point T Unit
set center system defined
At this p oint the classes have b een translated into typ es The only di erence b etween
typ es and classes remaining at this p oint is the di erence b etween concrete type and
type typ e sp eci ers and b etween T X and C X names
Re exive constants Since classes as well as typ es can b e used in expressions as ob jects
this translation step adds appropriate constant de nitions for every class de ned in the
program There are four cases
In nite classes If a class C T implementing a typ e T T has b een sp eci ed as infinite
the following constant de nition is added to the program
const T InfiniteClass T T C T
An in nite class do es not have an extent and can not create ob jects
Finite classes If a class C T implementing a typ e T T has b een sp eci ed as finite the
translation adds
const T FiniteClass T T C T
A nite class can not create ob jects but it has an extent The typ e T FiniteClass X
de nes b ehavior extent T Set X that returns a set of ob jects the extent of the
class
Manual classes Classes sp eci ed as manual can create ob jects and do not maintain
extent For eachmanual class C T implementing a typ e T T the following de nitions
are generated
const T ManualClass T T C T
association T ManualClass T T
const field type const field n type C T
new C T system defined
where each const field k type is a typ e assigned in the class sp eci cation to the
k th constant eld including inherited elds The b ehavior de ned here creates a
new ob ject of class C T For example the class sp eci cations
manual class C Person implements T Person
const T Natural age
manual class C Child subclass of C Person implements T Child
const T Set T Toy favoriteToys
will eventually generate the de nitions
const T ManualClass T Person C Person
association T ManualClass T Person T Natural C Person
new C Person system defined
const T ManualClass T Child C Child
association T ManualClass T Child
T Natural T Set T Toy C Child
new C Child system defined
Regular classes If a class is sp eci ed as a regular class or without an explicit sp eci er
the de nitions b eing generated are the same as for the manual class The only change
is in the name of the parametric typ e b eing assigned to the class constant namely
T Class T T instead of T ManualClass T T Regular classes maintain extents and
are capable of ob ject creation therefore the typ e T Class X is a subtyp e of b oth
T FiniteClass X and T ManualClass X The class typ e hierarchy is depicted in
Figure
Function co de translation In addition to the translation of typ e b ehavior and class sp eci ca
tions the translation of function co de also has to b e p erformed Translation of all interesting
features will b e presented here translation of standard language op erators is trivial and is
therefore omitted
Return elimination If the function co de has the form
expr return expr
it is translated into
expr expr
Otherwise no explicit return it has the form hexpri and is translated into
expr unit
Unit where unit is a prede ned ob ject of typ e T
Op erator elimination All op erators present in the co de are translated into their equivalent
b ehavioral form with an explicit receiver For example the co de
a b c
will b e translated into
a plus b divide c
Lo cal variables Every lo cal variable declaration
type name
is transformed into
let T Var type name new C Var type in
the rest of the function code up to the closing
Also every o ccurrence of a lo cal variable name x in the simple assignment context
x expr is translated into x set expr while every o ccurrence outside of the
simple assignmentcontext is translated into x get Thus the co de
T Integer k l
k k add l
will b e translated into
let T Var T Integer k new C Var T Integer in
k set k get add l get
Assignment elimination Simple assignments of the form
name expr
are transformed into the equivalent b ehavioral form
set name expr
All the other assignments have the form
expr name args expr
and are transformed into the equivalentbehavioral form
expr set name args expr
Since all lo cal variable assignments have already b een eliminated all the simple assign
ments left are assignments to settable b ehaviors of the implicit receiver The implicit
receiver will b e made explicit later on in the translation pro cess
If there are any assignments left at this stage the program is invalid and is rejected For
example during assignment elimination the following co de
aString substr k l aString
age k add l
is translated into
aString set substr k l aString
set age k add l
Explicit receiver Every function that participates in an asso ciation is transformed to take
its explicit receiver as the rst argument The identi er self is used to represent the
receiver In the function co de all b ehavior names name that are neither preceded
by a dot nor app ear in the construct protect name are replaced by self name
Names that app ear as protect name are replaced by name Theprotect construct
is designed to protect b ehaviors from b eing interpreted as b ehavior applications to the
implicit receiver For example function
fun x return fun r return age minus r minus x
will b e transformed into
fun self x
return fun r return self age minus r minus x
provided it is a part of an asso ciation On the other hand the function
fun return map protect negate
will b e transformed into
fun self return self map negate
rather than into
fun self return self map self negate
b ecause of the presence of protect
Multiple argument elimination Functions are made to accept a single argumentofa prod
uct typ e rather than multiple arguments This transformation is done to simplify typ e
checking It is p ossible b ecause b oth the source and the target language havemultiple
dispatch The co de is transformed in the following manner all de nitions
fun a aN expr
where N are translated into
fun x let a x in let a let aN x N in expr
where x is a fresh variable For example the co de
fun self x
return fun r return self age minus r minus x
is translated into
fun x let self x in let x x in
return fun r return self age minus r minus x
Ob ject creation Ob ject creation in the source language is done by using op erator new on
classes The translation pro cess transforms the op erator new whose syntaxisgiven b elow
new operator new class name initializers
initializers initializer initializer
initializer name expr
into a series of b ehavior applications in the following manner First the template for the
co de is generated
let n class name new class name args in tail n
where n is a fresh variable and the meaning of args and tail is de ned b elow For
each initializer name expr used in a given new op erator two cases are considered
There is a constant immutable eld name de ned on or inherited by the class
class name Then the expression expr is added to args in the p osition
corresp onding to the numb er assigned to the eld by the class translation pro cess
describ ed earlier
Otherwise the expression n set name expr is added to the tail
Consider the sp eci cation
class C Circle implements T Circle
T Point center
const T Length majorAxis
class C Ellipse implements T Ellipse extends C Circle
const T Length minorAxis
and the co de
new C Ellipse center aPoint
majorAxis axis minorAxis axis
It will b e translated into
let n C Ellipse new C Ellipse axis axis in
n set center aPoint n
since the eld center is up datable while the other elds are not
typeif expressions These expressions are designed for typ e safe re ection and have a sim
pli ed syntax
typeif expr
typeif name is type then expr
They check if the run time of name is a subtyp e of type and execute the expression
expr only if it is In the expression expr it can therefore b e assumed that the typ e
of name is at least type This last feature makes the typeif expressions sp ecial in
terms of their typing
During the translation for each typeif expression the b ehavior asso ciation
association T Object type as type fun x system defined
is added to the target language program and the expression itself is transformed into
let name name as type in
if name notEqual UNDEFINED then expr
The b ehavior as type has the following semantics it returns an ob ject UNDEFINED
of typ e T Null if its receiverhasatyp e that is a subtyp e of type and returns the
receiver otherwise Therefore its result typ e is always at least type
For example as a result of the translation of expression
typeif anObject is T Person then anObject age
the asso ciation
association T Object T Person as T Person fun x system defined
will b e added to the program while the expression itself will b e translated into
let anObject anObject as T Personin
if anObject notEqual UNDEFINED then anObject age
Dot elimination Finally the dot notation used in the co de so far is dropp ed in favor of
functional notation The b ehavior application expressions of the form
expr exprB expr exprN
are transformed into
exprB expr expr exprN
For example the expressions
aString substring
aPerson age
are transformed into
substring aString
age aPerson
Final touch The nal step of the translation from the source to the target language consists of
adjustment of the global program structure First typ e subtyp e b ehavior and constant
de nitions of the basic system are added Second all de nitions are group ed together in the
target program sections typ es subtyp es constants b ehaviors and asso ciations Third dupli
cate de nitions are discarded two de nitions are duplicates of each other if they are identical
up to whitespace elimination and free variable renaming Finally the named de nitions are
analyzed If there are two di erent de nitions for the same name it is an error unless both
con icting de nitions are b ehavior de nitions
In this section the target language has b een describ ed The target language presented is a simpli
ed version of the full language that is sp eci cally tailored for typ echecking purp oses Then the
translation from the source language into the target language was describ ed and illustrated In the
next section typ echecking algorithms for the target language will b e presented
Consistency
Typ echecking a program in the target language though signi cantly simpler compared to a source
language program is still a complicated task There are several asp ects to the issue of correctness
of a target language program that will b e considered in this section Some of those asp ects are
local in that they can b e veri ed by considering a single de nition others are global and deal with
interactions b etween various de nitions given in the program
The entailment algorithm describ ed in Section forms the basis of the algorithms presented
here in a sense target language program typing is simpli ed even further b efore this core algorithm
is used This section will provide the description of this simpli cation pro cess
This section is organized as follows First a formal notation for reasoning ab out typ es and certain
basic notions suchastyp es constrained typ es entailment and variance annotations are intro duced
in Section The remaining sections describ e various steps of program veri cation in the order
they are to b e p erformed First lo cal monotonicitychecking is describ ed in Section Then the
set of typ e sp eci cations given by the user is checked for acyclicity and complexity This pro cess is
describ ed in Section After these conditions are checked typ e expansions whichisaformof
typ e expression simpli cation can b e p erformed This is describ ed in Section After this task
is completed the main algorithms of Section can b e applied These algorithms are used in all
subsequent steps of the veri cation pro cess Section describ es veri cation of the user supplied
constraints After these are veri ed global b ehavior sp eci cation consistency is tested This step
is describ ed in Section The next step describ ed in Section p erforms typ e derivation
and checks consistency of function and program b o dies with resp ect to their sp eci cations This is
where most of the typ echecking o ccurs Finally on the last step the dispatch consistency absence
of message not understo o d and message ambiguous errors is veri ed This last step is describ ed
in Section
Notation
Formal reasoning ab out typ es has an established notation For instance AC BM a GM
QKB AW as wellasmany others use notations based on the common principles that will b e
describ ed in this section
This section presents an informal overview of the theoretical notions b ehind the typ echecking
algorithms It gives su cient information to implement and use the typ echecking algorithms pre
sented in this chapter The formal treatment of all the concepts presented here will b e given in
Chapter
Typ e constructors are represented by either lowercase Latin letters a b or bytyp e names
T A T B Typ e variables are represented by Greek letters and arbitrary typ e expres
sions are represented by upp ercase Latin letters A B C The notation A is used to denote a
typ e expression with free variables and the notation A B denotes a typ e expression
n
A in whichtyp e expressions B have b een substituted for variables The shortcut A A
i i n
will b e used for pro duct typ es T Product A A and the shortcuts A R and A R will b e
n n b
used for functional and b ehavior typ es T Function A R and T Behavior A R resp ectively The
typ e op erators lub and glb will b e used to denote the least upp er b ound and the greatest
lower b ound of a given set of typ es The syntax of typ e expressions is given b elow
A a j j a A A j A A j A A j A A j lub A A j glb A A
n b n n n
The typ e a A A is considered valid i a has arity n The typ e expression a is a shortcut for
n
a and thus requires a to b e of arity
For example b oth A a b d and B d b a c are typ e expressions A has a set of
free variables FTV A f g and is open while B has an empty set of free variables and is therefore
closed The term primary functor pfunctor will b e used to denote the outermost typ e constructor
of a simple typ e For example pfunctor A a and pfunctor B d
In the theoretical part of this dissertation closed typ es are mo delled as regular trees over the
alphab et de ned by the set of all typ e constructors plus the typ e op erators lub and glb Intuitively
a regular tree is a closed p ossibly in nite typ e expression that can b e describ ed in a nite form
For every closed ground typ e there is a corresp onding regular tree that represents it An example
of an in nite regular tree is a solution of the typ e equation b which is an in nite closed
typ e expression b b b There is a subtyping relationship denoted de ned on regular
trees de ned in Chapter by the relationships sp eci ed by the user in the user typ e graph G see
Section page see also De nition b elow Subtyping is a partial order over the domain
of ground typ es
Constraints and entailment
Constraints are inequalities b etween typ e expressions For example
a a
is a constraint Constraint satis ability is de ned over the domain of regular trees describ ed earlier
Namely a constraintissatis able if there is a set of regular trees valuation such that when these
regular trees are substituted for variables the constraint in question b ecomes true A sp ecial case
of a constraint is a constraint denoted as TRUE which is considered to b e satis ed for
n
all values of
n
A constraint set or a constraint conjunction is de ned as a conjunction of a nite number of
constraints Satis ability of a constraint set is de ned as existence of a valuation that turns the
constraint conjunction into a true formula T Integer is an example of an unsatis able
constraint while
T Integer
is an example of a satis able constraint set conjunction Constraint sets will b e denoted C in the
rest of this dissertation
Entailment is a relationship b etween two constraint sets de ned as follows
def
C C C C
In other words a constraint set entails another if for eachvaluation of the rst set that turns it into
a true statement there exists a valuation of the second that turns it into a true statementsuchthat
these twovaluations give the same values to variables that participate in b oth of them
The relationship can b e intuitively understo o d as follows If there are two sets of constraints
C and C then C C is true if and only if the second constraint set follows from the rst The
statement C therefore has a meaning that C is satis able Use of subscript G in means that
G
the entailmentischecked in the context of the typ e system de ned by the user typ e graph G
For example but Another example of true entailmentis
T Integer
as it states that there exists a typ e that is a subtyp e of T Integer However the formula
TRUE T Integer
is false since it states that anytyp e is a subtyp e of T Integer whichisobviously false
The veri cation algorithm for will b e given in Section
G
The notion of entailmentintro duced ab oveiscentral to the typ echecking mechanism presented
in this dissertation All typ echecking tasks are ultimately formulated in terms of entailment
Constrained typ es
The typ es and constraints describ ed ab ove are used in the construction of constrainedtypes A
simple constrained typ e has the following form
C A
n
where C is a constraintset A isatyp e and are typ e variables free in A and C The
n
syntax of simple constrained typ es is as follows
X C A
n
C A A j C A A
We will often omit the quanti cation and write C A instead of C A When the
n
constraints are empty they will also b e omitted For example b oth X b and Y b are
simple constrained typ es Their unabbreviated form is b and b resp ectively
The intuitive meaning of a simple constrained typ e C A can b e understo o d as
n
follows Let S b e the set of all closed typ es A T suchthatT are closed typ es satisfying the
i
subtyping constraints C T Then the simple constrained typ e C A denotes the set
n
of all greatest lower b ounds of S For example consider the simple constrained typ e b
The set S is the set of all typ es that are sup ertyp es of b The greatest lower b ound of S is b and
therefore b b This can b e directly veri ed by using De nition
Subtyping de ned on ground typ es induces subtyping on simple constrained typ es de ned as
follows
De nition Subtyping of simple constrained typ es
def
C A C A C C A A
where the quanti cation is over the domain of ground typ es
This de nes subtyping as a partial order over the domain of simple constrained typ es factored
def
by the equivalence relationship de ned as X Y X Y Y X Intuitively the
equivalence relationship allows one to identify syntactically di erent but semantically equivalent
simple constrained typ es like b and b considered ab ove
The following is the intuitive meaning of the ab ovesubtyping de nition If X and X are simple
constrained typ es denoting resp ectively sets S and S thenX X i for each element s of S
there is an element s of S suchthats s For example consider the simple constrained typ e
X T Integer
f
X denotes all function typ es that accept an argumentofanytyp e which is a subtyp e of T Integer
f
and pro duce the result of the same typ e as the argument supplied What is the relationship b etween
X and the function typ e X T Integer T Integer The typ e X corresp onds to a singleton set
f i i
Integer T Integer itself This element b elongs also to the set denoted by X and consisting of T
f
therefore X X butX X In order to see why this is the case consider using a function f of
f i f i
Integer and pro duces the result of typ e X where X is exp ected f accepts arguments of typ e T
f i
typ e at least T Integer and thus conforms to the sp eci cation given by X On the other hand an
i
attempt to use a function i of typ e X where X is exp ected leads to a typ e error since X not only
i f f
Integer but also to b e of at least the same typ e as its argument requires its result typ e to b e T
The sp eci cation X guarantees the rst of these two requirements but not the second
i
Note that if C is an unsatis able set of constraints then X C A for any X and A Thus
constrained typ es with unsatis able constraint sets play the role of the top typ e in the hierarchy
denoted Typ es of the form on the other hand play the role of the b ottom typ e denoted
The notion of a primary functor is generalized for simple constrained typ es The primary functor
of a simple constrained typ e X C A is de ned to b e the primary functor of A
Note that the notation used for typ es and simple constrained typ es intro duced in this section
is parallel to the notation used to sp ecify typ es subtyp es and constraints in the target language
Section This prop erty of the target language will enable the description of consistency
conditions directly in terms of the notation de ned here with no additional translation steps
Simple constrained typ es are further generalized to constrainedtypes A constrained typ e has a
form X glb X where X are simple constrained typ es The intuitive meaning is that if eachof
i i
i
X denotes a set of typ es S then X denotes a set of typ es S which is the set of all lower b ounds
i i
S
of the union S Subtyping is also trivially generalized for the constrained typ es as given in the
i
i
following de nition
De nition Subtyping of constrained typ es
def
glb X glb X j i X X
i i j j i j
For example
Integer T Integer T Real T Real T Real glb T
even though
T Integer T Integer T Real T Real
This generalization is useful in describing b ehavior typ es for b ehaviors that haveseveral typ es
signatures de ned for them For example cat concatenation can have b oth signatures
List T List T List T
and
T String T String T String
Then the typ e of cat can b e precisely describ ed by the constrained typ e
List T List T List T String T String T String glb T
Constrained typ es will b e denoted by the upp ercase Latin letters X Y Z W in the rest of this
dissertation
Variance annotations
Variance annotations are variable annotations that are drawn from the set f g An anno
tated typ e expression is a typ e expression with variables annotated by one of covariance
contravariance or novariance For example a b c is an annotated typ e expression
If a particular o ccurrence of a variable in a typ e expression is annotated by it means
that the typ e expression changes covariantly contravariantly novariantly with typ es substituted
for that o ccurrence of the variable For example consider a typ e expression A that consists of
and t b e some typ es When weuse t for in A we obtain just a variable i e A Lett
A t when we use t we obtain A t Since
t t A A
the only o ccurrence of in A iscovariant and should b e annotated by A A more
complicated example is the typ e expression B Here the two o ccurrences of have
di erentvariances Namely consider the rst o ccurrence B t and B t and therefore
t B B t
Thus the rst o ccurrence of in B iscontravariant Consider the second o ccurrence In this
case B t and B t and therefore
t B B t
Table Variance combination
Thus the second o ccurrence is covariant Therefore the annotated expression will b e B
The following algorithm formalizes the pro cess of annotating a given typ e expression Given a
typ e its canonical annotatedformis de ned as follows
De nition Canonical annotated form CAF Given a typ e expression A its canonical
annotated form is given by the annotation algorithm given b elow with the call annotate A
a if A a
v
if A
a A A if A a A A
n
n
where A annotate A Var a i v
i
i
annotate A v
lub A A if A lub A A
n
n
where A annotate A v
i
i
glb A A if A glb A A
n
n
where A annotate A v
i
i
Here Var a i is de ned according to the prede ned variance of the i th parameter of the typ e
constructor a as follows it is if the parameter is de ned as covariant if it is de ned as con
travariant and if it is de ned as novariant The commutative binary op eration on variances is
de ned byTable
For example the CAF of the expression a b is
annotate a b
annotate a annotate b annotate
annotate a annotate b annotate
a b annotate annotate
a b annotate annotate
a b annotate annotate
a b
since the rst argumentof is de ned as contravariant while the second one is de ned as
covariant at the same time all arguments of a pro duct typ e are de ned as covariant
Once a CAF C of a typ e is computed its variancesetV is de ned as a set of tuples of the form
h S i where is a typ e variable and S is a set of all variances assigned to in C S can b e also
thoughtofasamapfromavariable name to a set of all its annotations in a given expression For
example
V a b V a b fh f gi h f gig
There is a partial order strength de ned on variance sets A variance set V is stronger then a
variance set V denoted V V i for eachtyp e variable suchthat h S i V there exists
h S i V such that either S S or S or f g S
For example
fh f gi h f gi h f gi h f gig fh f gi h f gi h f gig
but
fh f gig fh f gig
The strength relationship de ned ab ove has the following meaning Assume that there are two
typ e expressions A and B that share some typ e variables Then if the variance set V
n A
of A is stronger then the variance set V of B the following holds
B
A r A r B r B r
for all closed typ e expressions r r r r For example let T List X beanovarianttyp e
n
n
Let A T List andB ThenV fh f gig and V fh f gig and therefore
A B
V V Let us check the prop erty Indeed
A B
List r List r T A r A r T
r r
r r r r
r r r r
B r B r
On the other hand if wetake A thenV fh f gig and V V In this case A r r
A A B
and A r r The prop erty is then formulated as
r r r r r r
which is false e g take r T Integer and r T Real
The notion of a canonical annotatedformis generalized for simple constrained typ es The
canonical annotated form for a simple constrained typ e X C A is de ned as follows
De nition Canonical annotated form CAF for simple constrained typ es
def
CAF L U L U A
n n
annotate L annotate U
annotate L annotate U annotate A
n n
For example the CAF of the constrained typ e is The
notion of a variance set is trivially generalized to constrained typ es as well
The ab ove de nition states that expressions on the left side of the subtyping relationship are
considered to b e in covariant p ositions while those on the right are considered to b e in contravariant
p ositions The following is the intuitive reason for this to b e true Let C b e a constraint
and let t and t b e suchtyp es that C t t is satis ed Then
a b a b
t t t t C t t
a b
a b a b
In other words a constraint remains true when the expression on the left changes covariantly and
the expression on the rightchanges contravariantly
Conclusion
In this section the notation for dealing with typ es constrained typ es and variance annotations
has b een established In the following sections this notation will b e used to establish consistency
conditions placed on the typ e system
In the following discussion the concrete typ e sp eci ers will b e omitted as they are not relevantto
typ e de nition consistency Also asso ciations will b e treated likebehavior de nitions their function
part will b e ignored Function asso ciations are only relevant to Section and Section while
the distinction b etween abstract and concrete typ es is only relevant to Section
Lo cal monotonicity
All typ e and b ehavior de nitions present in the program are required to b e local ly monotonic Lo cal
monotonicity corresp onds to the intuition that a parametric typ e b ehavior de nition has to ensure
that the typ e b ehavior b eing de ned maintains its validity in the presence of covariantchanges in
its parameters The conditions for lo cal monotonicity are outlined b elow
De nition Lo cal monotonicity
A typ e de nition of the form
v
v
n
type C a
n
is local ly monotonic i
fh fv gig V C
i i
A b ehavior de nition of the form
behavior C A R h namei
is local ly monotonic i
V A V C V R
For example consider the typ e sp eci cation
type X T Ordered X T OrderedSet covar X
Its constraint set is C T Ordered The CAF of the constraint set is C
T Ordered i e T Ordered The variance set of constraints is therefore
V C fh f gig On the other hand the variance set of the b o dy is V fh f gig and
therefore V V C Therefore the typ e sp eci cation under consideration is monotonic
On the other hand the typ e sp eci cation
type T Natural X T SpecialSet covar X
Natural thevariance set of con is not monotonic since CAF of the constraints is C T
straints is V C fh f gig thevariance set of the b o dy is V fh f gig andV V C
Therefore the typ e de nition ab ove is rejected
In the presence of typ e de nitions
type c
type n
the b ehavior de nition
behavior c pick
will b e monotonic
V A V c f f gg f f gg V
while the b ehavior de nition
behavior n createRef
will not b e considered monotonic
V A V f f gg f f gg V n
and will therefore b e rejected
The lo cal monotonicity condition is never used in the theory and can b e lifted without impacting
its correctness The reason for intro duction of this restriction is not a theoretical but a practical
one Namely while typ echecking will work just as well in the presence of non monotonic typ e
sp eci cations interpreting its results would b e a challenge To illustrate this p oint consider the
List of up datable lists b e de ned as following example Let a typ e T
type T List novar X
and let inject b e the b ehavior with the following intended semantics inject appliedtoanobject
o of anytyp e X pro duces a list of typ e T List X thatcontains a single element o The sp eci cation
of inject will therefore b e as follows
behavior X T List X inject
The typ e of inject will therefore b e
T T List
b
which is not monotonic The meaning of this typ e as interpreted by the typ e system is drastically
di erent from what the user might exp ect Namely thetyp e system assumes that inject has al l the
typ es denoted by T for di erentvalues of This means that a function that implements inject
List forany receiver ob ject of typ e is required to pro duce an ob ject of the typ e R glb T
X
X Clearly noobjectcansimultaneously p ossess typ es T List for all below X and therefore a
function implementing inject can never b e written Thus even though typ echecking of expressions
involving inject pro ceeds almost as exp ected the assumptions that the typ e system makes ab out
the meaning of the typ e T are counterintuitive at b est In order to avoid situations like these the
monotonicity restrictions are placed on all typ e sp eci cations app earing in a program
In this section the concept of local monotonicity has b een constructively de ned The lo cal
monotonicity de nition is at the same time an algorithm for checking lo cal monotonicityoftyp e
b ehavior and function de nitions
Simplicity and the user typ e graph
The typ e system and the systems of typ e constraints used in the program should de ne subtyping
as a partial order In addition to that the de ned order should b e simple enough to guarantee
the termination of the algorithms describ ed in Section In this section it will b e shown how the
ab ove conditions are formulated and veri ed
In order to formulate and deal with these conditions the notion of the user typegraph G is
intro duced It will b e used later to de ne and check acyclicity and simplicity conditions
De nition User typ e graph G G is a directed graph with lab eled edges Vertices in G
are the typ e de nitions of the given program G has an edge from a to b i there is a subtyp e
de nition of the form
C a A b B
in the program The edge is lab eled by the subtyp e de nition ab ove
Thus the user typ e graph is a directed graph with lab eled vertices and edges
It is required that G be acyclic This is a su cient condition for the subtyping de ned by the
set of de nitions to b e a partial order as will b e shown in Chapter For the theoretical treatment
of typ es and subtyping this is all that is needed However this is insu cient to ensure termination
of the core entailment algorithm used for typ e checking
In order to see why this is the case consider the following de nitions
type T List novar X
T SpecialList X T List X T SpecialList X T List X
What this de nition is saying is that T SpecialList X is asubtyp e of T List X if
T SpecialList X is a subtyp e of T List X an apparent recursion When an algorithm at
tempts to establish whether a given typ e T SpecialList A isasubtyp e of another typ e T List A
it checks the condition rst thus going into in nite lo op Of course this is a trivial example but it
do es show that acyclicity of the typ e graph alone do es not guarantee termination
Therefore it is also required that G has a valid ranking Avalid ranking is informally an as
signment of di erent p ositive complexity indices to all typ e constructors in the graph One typ e
constructor is more complex than the other if the second one can b e used to test some subtyping
hyp othesis involving the rst one As long as this more complex relationship do es not haveany
cycles in the graph assignment of complexity indices is p ossible Considering the ab ove example
with T List and T SpecialList we can see that T List is more complex than T SpecialList
SpecialList A T List B For the same since the later is required to verify the hyp othesis T
reason T SpecialList is more complex than T List and therefore the typ e graph de ned by this
example do es not haveavalid ranking
The formal de nition of valid ranking as well as the algorithm that checks whether a given graph
G has a valid ranking is given b elow
De nition Ranking and valid ranking Ranking is an assignment of p ositiveinteger num
b ers ranks a to all typ e constructors with non zero arity a in G Avalid ranking is a ranking such
that
For eachpathP between two constructors a and b in the user typ e graph G the following
condition holds
max E R min fa bgnI
Here E is a union of rank sets for all edges in the path P R is a union of rank sets for all
vertices in the path P and I is the set of all ary typ e constructors in G It is assumed that
max and min The op eration n denotes set theoretical di erence
For non ary typ e constructor a in G the following condition holds
max E a
a
where E is the rank set of the vertex a in G
a
A rank set for an edge is de ned as a set of ranks of all non ary typ e constructors that participate
in the lab el of that edge in p ositions other than primary functors of the principal inequality In other
words if the lab el of the edge is
C a A b B
then the rank set for this edge includes ranks of all non ary typ e constructors participating in
C A and B
A rank set for a vertex is de ned as a set of ranks of all non ary constructors participating in
conditions placed on the lab el of the vertex In other words if a vertex a is lab eled with
type C a
then the rank set for this vertex will include ranks of all non ary typ e constructors that participate
in C
Given a set of typ e and subtyp e de nitions the set of inequalities b etween constructor ranks
that de nes a valid ranking is constructed Each inequality has the form
max set of ranks S min fa b g
i i i
and can b e represented as
s a s b
i i
s S
i
Avalid ranking is a ranking that satis es all inequalities i e satis es the formula
s a s b
i i
i
s S
i
This formula has the form
a a a a a a
n n
wherea are not necessarily distinct rankings Such a conjunct de nes a directed graph G with
i
verticesa and edgesa a for all inequalitiesa a in the conjunct If G is acyclic there exists
i i j i j
a ranking such that the formula is satis ed Such ranking is a valid ranking
Thus checking for the existence of a valid ranking is done as follows
A formula of the form describ ed in Equation is constructed
The graph G is constructed and checked for acyclicity If it is acyclic succeed otherwise fail
As an example consider the set of typ e and subtyp e de nitions
type T Printable
type T Set covar X
X T Printable T Set X T Printable
type T OutputStream contravar X
type T SetOS novar X
T SetOS X T Set T OutputStream X
For brevity p will b e used for T Printable s for T Set o for T OutputStream and q for T SetOS
The ab ove de nition can b e represented in theoretical notation as
type p
type s
p s p
type o
type q
q s o
type p type o
p s p
type s
q s o
type q
Figure Example user typ e graph G
The user typ e graph G for this hierarchy is presented in Figure
There are three p ossible paths in this graph s p q s and q p Only these paths contribute
to the resulting formula since all vertex rank sets are empty Edge rank sets are fp g for s p and
fs g for q s The inequalities are as follows
s for s p
o min q s for q s
o q for q p
and the formula Equation is
o q o s
This fromula de nes an acyclic graph G and therefore a valid ranking exists
In this section acyclicity and simplicity conditions have b een describ ed The notions of the
user typegraph and a valid ranking were de ned and used to formulate the ab ove conditions The
algorithm for checking the simplicity condition has b een presented and exempli ed
Typ e expansion
In order to p erform the necessary checking the concept of typeexpansion is used Informally a typ e
expression is expanded if it explicitly lists all the constraints implicit in the de nitions of typ es that
participate in the expression For example if wehave the de nition
type X T Person T PersonList novar X
then the following typ e expression is not expanded
T List
while the next one is
T Person T List
The following is the formal de nition of an expanded typ e
De nition Expanded typ e A simple constrained typ e C A a constraint set C is called
expanded if for every sub expression of the form a B that o ccurs is C A a constraint set C the
following holds
if
type C a
is the typ e de nition of a then C B C
The pro cess that transforms a typ e into its expanded form is called expansion and is p erformed
by recursively adding appropriate constraints to the constraint set This pro cess is describ ed by the
following algorithm
Algorithm Typ e expansion
Initialize Set S to b e the set of all sub expressions in C and A which are neither variables nor ary
constructors set R to b e equal to C setS to b e the empty set
Add For each expression a B inS do the following
Add C B toR
Add all sub expressions in C B which are neither variables nor ary constructors to
S
where
type C a
is the typ e de nition of a
Iterate S S n S if the resulting set S is empty succeed with the result R A otherwise let
S and continue from step Add
Expansion is guaranteed to terminate if there exists a valid ranking as will b e shown in Chapter
For example given the typ e de nitions
type p s
type s q
the following typ e expression is not expanded
q
However it can b e transformed into expanded form as follows
q s q s p q
The expansion function expand provides the expanded form of a typ e expression For exam
G
ple expand q s p q Since the typ e expansion step is p erformed after the
G
existence of a valid ranking for the user typ e graph has b een established the function expand is
G
well de ned
Convention From nowon alltyp es in the program are considered to b e expanded
This can b e done by means of the syntactic transformations
Eachtyp e de nition
type C a
is transformed into
type C a
where expand C a C a
G
Each subtyp e de nition
C A A
is transformed into
C C A A
A
A
where expand C A C A and expand C A C A
G A G
A
Each b ehavior de nition
behavior C A R
is transformed into
behavior C C A R
A R
where expand C A C A and expand C R C R
G A G R
Each b ehavior asso ciation is transformed analogously to the b ehavior de nition
Note that neither constant de nitions
const A hnamei
nor the typedletexpression
let A hnamei
are transformed since A in b oth cases is not allowed to contain typ e variables thus the resulting
constraints C are either inconsistent which will b e rejected by consistency checking or if consistent
C A A
The expansion pro cess is describ ed here since it can only b e done after the user typ e graph is
successfully checked for simplicity existence of valid ranking
Constraint consistency
Constraint consistency checkingisneededtoidentify erroneous unsatis able constraints i e con
straints that can not b e satis ed byany p ossible typ e This section provides the algorithm for
constraint consistency checking in the given typ e system
An intuitive reason for consistency checking is the fact that constrained typ es of the form C A
are equivalent to the top typ e in the hierarchy when their constraint sets C are unsatis able
Since it is the purp ose of typ echecking to ensure that data of the typ e can never b e generated by
the program the initial conditions describ ed bytyp e sp eci cations given explicitely in the program
are also required to sp ecify typ es strictly less than The last requirement is equivalenttothe
requirement of satisfyability of constraints of all typ es sp eci ed by the user
De nition Constraint consistency Each of the following constructs
A typ e de nition of the form
type C a
A subtyp e de nition of the form
C a A b B
A b ehavior de nition of the form
behavior C A R
has a consistent constraint i
C
G
It is required that all typ e subtyp e and b ehavior de nitions in the program have consistent
constraints
Note that this step can only b e done after simplicitychecking since only in a su ciently simple
typ e system is the algorithm of Section guaranteed to terminate
Consider the following sp eci cation
type T Person
type T Child
T Child T Person
type T Child X T Array novar X
behavior X T Person T Array X X getOldest
For brevity p will b e used for T Person c for T Child a for T Array and b for getOldest The
ab ove de nition can b e represented in theoretical notation as
type p
type c
c p
type c s
behavior p a b
Consider the question of constraint consistency for the b ehavior sp eci cation present in the ab ove
fragment The expanded form is
type p
type c
c p
type c s
behavior p c a b
and the b ehavior constraint set is therefore
C p c
The formula
C p c
G G
is satis ed since there exists an such that all constraints in C are satis ed for example c
Therefore the constraint is consistent
On the other hand if the subtyp e de nition
T Child T Person
was removed the ab ove constraintwould b e inconsistent The reason for that is that nowitis
imp ossible to nd an to satisfy the formula
p c
since the latter requires that
c p
and this is no longer the case Therefore the formula
C
G
is not satis ed and the constraint is inconsistent
In this section the notion of constraint consistency was intro duced The pro cedure for checking
constraint consistency has b een established and exempli ed
Global b ehavior consistency
Behavior de nitions have to b e consistent Since several b ehavior de nitions can collectively de ne
a single b ehavior there are two asp ects of consistency lo cal monotonicity a single de nition and
global monotonicity a set of all de nitions for the same b ehavior The lo cal monotonicity has b een
de ned in Section The global consistency related to interaction b etween di erent de nitions
of the same b ehavior is describ ed in this section
Note that lo cal monotonicity conditions are not essential for the theory to b e applicable They
are designed to reject the sp eci cations that haveacounterintuitive meaning but in their absence
typ echecking algorithms will still b e valid and sub ject reduction will b e provable On the other hand
the global monotonicity considered here is crucial Without it a correctly typ echecked program can
pro duce typ e errors during its execution
De nition Global b ehavior consistency Abehavior b is global ly consistent i for every
two de nitions
behavior C A R b
and
behavior C A R b
the following holds
C C fA A g R R
G
All b ehaviors are required to b e globally consistent The algorithm for checking the entailment
will b e presented in Section
Consider the following sp eci cations
type T Real
type T Integer
T Integer T Real
behavior T Real T Real T Real add
behavior T Integer T Integer T Integer add
For brevity r will b e used for T Real i for T Integer and b for add The ab ove de nition can b e
represented in theoretical notation as
type r
type i
i r
behavior r r r b
behavior i i i b
In order to check the consistency it is neccessary to check b oth directions and
Here C C and r r i i is unsatis able Therefore the consistency
condition is trivially satis ed
Here C C and i i r r is trivially satis ed It is left to show that
i r
G
which is immediately true Therefore the consistency condition in this case is also satis ed
Thus the ab ove b ehavior sp eci cations are globally consistent
A more complicated example dealing with parametric typ es will b e considered next
type T Set covar X
type T Array novar X
T Array X T Set X
behavior T Set X T Set X someSubset
behavior T Array X T Array X someSubset
For brevity s will b e used for T Set a for T Array andb for someSubset Theabove de nition can
b e represented in theoretical notation as
type s
type a
a s
behavior s s b
behavior a a b
Again it is necessary to check b oth directions
Here C C and s a is unsatis able Therefore the consistency
condition is trivially satis ed
Here C C and a s since for any and
a s It is left to show that
a s
G
which is immediately true Therefore the consistency condition in this case is also satis ed
Thus the ab ove b ehavior sp eci cations are globally consistent
An example of an inconsistentbehavior sp eci cation is given b elow
type T Set covar X
type T MySet
type T Person
T MySet T Set X
behavior T Set X X pick
behavior T MySet T Person pick
For brevity s will b e used for T Set m for T MySet p for T Person and b for someSubset The
ab ove de nition can b e represented in theoretical notation as
type s
type m
type p
m s
behavior s b
behavior m p b
Checking b oth directions
Then C C and s m is unsatis able Therefore the consistency condition
is trivially satis ed
Then C C and m s TRUE since the constraint m s trivially
holds for all It is left to showthat
TRUE p
G
which is not true since there exist suchthatp do es not hold Note that the presence
of TRUE on the left side of the turnstyle is crucial
TRUE p p FALSE
G
while
p p TRUE
G
Therefore the consistency condition in this case is not satis ed
Thus the ab ove b ehavior sp eci cations are not globally consistent and will b e rejected In order to
see why these sp eci cations are incorrect consider an application of the b ehavior pick to an ob ject
MySet statically declared to b e of typ e T Set T Student Statically the result typ e will of typ e T
b e inferred to b e T Student according to the rst sp eci cation However at run time the call will
b e dispatched to the second asso ciation as T MySet is more sp eci c than T Set However the
second asso ciation is only required to pro duce an ob ject of typ e T Person and not necessarily of
typ e T Student Thus a run time typ e error will o ccur
In this section the algorithm for checking global b ehavior consistency was describ ed and exem
pli ed The next section deals with the issue of functional consistency i e checking whether the
sp eci ed function co de corresp onds to the typ e sp eci cations given for that function
Functional consistency
In this section typ echecking of function co de will b e describ ed All co de in the target language
except for the main expression of the program is contained in functions and functions are
asso ciated with b ehaviors by associations The algorithm presented in this section ensures that
asso ciations are lo cally consistent i e that the function b eing asso ciated indeed conforms to the
typ e sp eci ed for it in the asso ciation
Function consistency checking pro ceeds as follows First the initial environment asso ciating
constants in a program with their declared typ es is constructed Then for each function asso ciation
its typ e is inferred and its validityisveri ed Finally the main expression of the program is
typ echecked These veri cation steps are describ ed b elow
De nition Initial environment An environment is de ned as a set of name to
i
typ e bindings of the form v glb C A Theinitial environment for a program is de ned as
i
i
follows
For eachconstant de nition of the form
const A v
the asso ciation v A is added to
For each b ehavior b the asso ciation v glb X X is added to where there is
N
i
X C A R for eachbehavior de nition
i i b i
i
behavior C A R b
i i
and for eachbehavior asso ciation
i
association C A R bfun
i i
The denotation v will b e used to denote if v is unb ound in and the typ e X if v is b ound
and its binding in has the form v X The op eration constructs the new typing
environment that includes all bindings in and those bindings of that are not overridden in
Formally
v if v
v
v if v
For example for a set of de nitions
Integer MaxAge const T
behavior T Real T Real T Real add
behavior T Integer T Integer T Integer add
the initial environment will b e
Integer add glb T Real T Real T Real fMaxAge T
b
T Integer T Integer T Integer g
b
De nition Functional consistency A program is functional ly consistent i
For each function asso ciation of the form
association C A R b fun x hexpri
the following holds
X C A R
G
where fun x hexpri X glb C A
i i
i
For the main expression hexpri of the program the following holds
C for at least one i
G i
where hexpri glb C A
i i
i
Note that the condition for the functional expression can b e equivalently written as
i C C A A R
G i i
The inference algorithm computing the relationship is presented in Figure The intuitive
meaning of the statement of the form
expr X
is that the expression expr has typ e X when all constants are typ ed according to The denotation
glb E j j where E j j issometyp e expression dep ending on j j is
n n n
j j
n
de ned as
def
E glb glb fE j j j dom j dom j g
j j j j n n
n j j n
n
i i
u glb C A u
i
Axiom
i i
u glb C A
i
i i
fx g hexpri glb C A
i
Abs
i i
fun x hexpri glb C A
i
where is a fresh typ e variable
j j
i i
hexpri glb C A hexpri glb C A
i j
Appl
j j
i i
hexpri hexpri glb C C fA A g
i j
where is a fresh typ e variable
j j
j j
n n
hexpri glb C A hexpri glb C A
j j n n
n
n
Pro duct
j j
i
j
n
A A hexpri hexpri glb C
i
n j j
i n
n
j j
i i
hexprsi glb C A hexpri glb C A
i j
Seq
j j
i
hexprsi hexpri glb C C A
i j
j j
i i i i
hexpri glb C A fx glb C A g hexpri glb C A
i i j
Let
j j
i
let x hexpri in hexpri glb C C A
i j
j j
i i
A hexpri glb C A fx T g hexpri glb C
i j
Typ edLet
j j
i i
fA T g A let T x hexpri in hexpri glb C C
i j
Figure Typing rules for the target language
Example Consider the following set of sp eci cations
Integer MaxAge const T
behavior T Real T Real T Real add
behavior T Integer T Integer T Integer add
association T Integer T Integer addMaxAge
fun x freturn add x MaxAge g
The initial environmentis
fMaxAge T Integer
Real T Real T Real add glb T
b
T Integer T Integer T Integer
b
addMaxAge glb T Integer T Integer g
b
In order to typ echeck the body of the behavior addMaxAge it is necessary to nd X such that
fun x add x MaxAge X
Let
i i
X glb C A
i
Using the rules in Figure the following derivation is constructed
Using the rule Abs is true if
i i i i
A glb C A glb C
i i
and
fx g add x MaxAge X
where
i i
X glb C A
i
Using the rule Appl the ab ove is true if
i j i j
i i
glb C A glb C C fA A g
i i j
and branch
i i
fx g add glb C A
i
and branch
j j
fx g x MaxAge glb C A
j
Following branch using rule Axiom since add is in the following is proven
i i
Real T Real T Real T Integer T Integer T Integer glb C A glb T
b b
i
Following branch using rule Pro duct
j j j j j j
A A C glb C A glb C
j j j
where branch
j j
fx g x glb C A
j
and branch
j j
C fx g MaxAge glb A
j
Following branch using the rule Axiom since x is in the set of assumptions it is proven
that
j j
glb C A
j
Following branch using the rule Axiom since MaxAge is in it is proven that
j j
T A glb C Integer
j
All branches have successfully terminated Now it is p ossible to synthesize the resulting typ e
expression X by following the derivation tree b ottom up
from
j j
glb C A
j
from
j j
glb Integer C A T
j
from and
j j
T A glb C Integer
j
from
i i
glb C Real T Real T Real A glb T
b
i
T Integer T Integer T Integer
b
from and
i i
Real T Real T Real T Integer glb C A glb T
b
i
T Integer T Integer T Integer T Integer
b
From and
X glb T Real T Real T Real T Integer
b
T Integer T Integer T Integer T Integer
b
The typ e X is the typ e inferred for the function b o dy
Finally from and
Real T Real T Real T Integer X glb T
b
T Integer T Integer T Integer T Integer
b
According to De nition one of the following conditions should b e satis ed for the sp eci
cation under consideration to b e functionally correct
T Real T Real T Real T Integer T Integer
G b
T Integer T Integer
or
T Integer T Integer T Integer T Integer T Integer
G b
T Integer T Integer
where the premises are empty since
Integer T Integer T Integer T Integer expand T
G
Formula is false since
T Real T Real T Real T Integer T Integer
G b
T Integer T Integer
T Integer T Integer T Real T Real
G
Real T Integer T Integer T
T Integer T Real T Real T Integer T Integer
G
T Real T Integer T Integer
G
FALSE
Real T Integer since T
However formula is true since
T Integer T Integer T Integer T Integer T Integer
G b
T Integer T Integer
T Integer T Integer T Integer T Integer
G
T Integer T Integer T Integer
T Integer T Integer T Integer T Integer T Integer
G
T Integer T Integer
G
TRUE
and therefore there is and such that the ab ove constraint is satis ed
Therefore the de nition of addMaxAge is considered to b e functionally consistent
In this section the notion of functional consistency was intro duced and the algorithm for its
checking has b een describ ed The typ e inferencing rules used in functional consistency checking
were de ned The typ e inferencing rules presented in this section together with the entailment
veri cation algorithm given in Section constitute the core of the typ e and consistency checking
Dispatch consistency
A uniform b ehavioral system in whichevery action is p erformed via a b ehavior application has to
supp ort an e cient run time dispatchmechanism In theory a dispatchmechanism can b e similar
in expressibilitytothetyp e sp eci cation mechanism of a language However the expressiveness
of a dispatchmechanism is inversely prop ortional to its complexity and therefore to its e ciency
Considering the fact that the dispatchmechanism is the main run time engine of a b ehavioral system
a certain compromise b etween expressiveness and e ciency is necessary
The material in this section is related to a particular dispatchmechanism that has b een chosen for
the describ ed system This mechanism supp orts multiple dispatch but ignores di erences b etween
di erent parametric typ es from the same parametric typ e family For example it is p ossible to
dispatch the calls equal aPoint aPoint and equal aPoint aColorPoint to di erent functions
However the dispatch of the calls aStudentSet pick and aPersonSet pick is required to yield the
same co de
Note that the validity of the calls can dep end on a particular typ e parameter e g the call
aNumberList sort is typ e correct while anObjectList sort is not Once the call is valid however
its dispatch should only dep end on the primary functors of the typ es involved
There are several asp ects related to the dispatch consistency First for every concrete typ e and
anytyp e correct b ehavior application involving that typ e the co de to dispatch to should b e de ned
no message not understo o d errors on statically typ e correct calls Second the co de to execute
should b e unambiguous no message ambiguous errors Finally the dispatchshouldalways yield
a function that was typ e checked with resp ect to typ es of actual arguments or their sup ertyp es
The last issue is the consequence of the compromise b eing made b etween the expressivepower
of dispatch mechanism and its e ciency Namely if the expressiveness of the dispatch mechanism
was equivalent to the expressiveness of the rest of the typ e system this issue would not arise
The following material describ es the algorithms used to check all three asp ects of dispatch con
sistency
Since the dispatch o ccurs at a coarser level concrete primary functor only typ es than a typ e
de nition do es for dispatch consistency checking it is necessary to b e able to deal with the b ehavior
asso ciations at b oth levels While the typ e sp eci cation is given directly in a b ehavior asso ciation
the concrete form of the typ e has to b e inferred The following algorithms are used to derivethat
form from the typ e sp eci cation given
De nition Concrete typ e constructors Atyp e constructor c in G is called concrete i
its corresp onding typ e de nition is of the form
concrete type C c
The set of all concrete typ e constructors in a given user typ e graph G is denoted Concrete
G
De nition Constructor pro ducts A tuple hc c i is called aconstructor product
n
over G if eachofc is a typ e constructor in G The relationship de ned by the graph G on typ e
i G
constructors is extended to constructor pro ducts in the following way
def
c i h hc c n m c c i c
G G m i
n i
i
n
The set of all constructor pro ducts of arity n is denoted Constr
G
De nition Primary form A primary form of a simple constrained typ e X
C A A is a constructor pro duct denoted primary X de ned as follows
N G
pfunctor A if A
def
i i
primary X hc c ijc
G n i
j j
g C g otherwise if A jf u glb fpfunctor u
j i
G
i i
Here the usual convention for unary pro ducts hAi A isused
The primary form is basically a simpli cation of a given typ e The given typ e is simpli ed up to
apoint when it can b e presented as a constructor pro duct This simpli ed form is the one used for
dispatch As an example consider the typ e
X T Integer T Real T List
Integer T Listi Indeed for the rst comp onentwemust compute the Its primary form is hT
greatest lower b ound of T Integer and T Real whichisT Integer For the second the primary
functor T List is taken according to the de nition ab ove
De nition Abstract form An abstract form of a constructor pro duct t ht t i
n
denoted abstract t is de ned as follows
G
def
Arity t
Arity t
n
abstract t expand t t
G G n
n n
i
where are fresh typ e variables
j
Computing an abstract form of a constructor pro duct is in a sense an inverse to taking a primary
form of a typ e The latter transforms a constrained typ e into a constructor pro duct while the former
transforms a constructor pro duct into a constrained typ e However since some information is lost
when the primary form is obtained abstract form of a primary form of a given constrained typ e
is in general di erent from the original For example the abstract from of a constructor pro duct
Integer T Listi is hT
Integer T List T
which is not the same as X
De nition Concrete set A concrete set for a set of simple constrained typ es fX
i
n n
C A g denoted concrete fX g is de ned as follows
i i G i
i i
m
If A A A for all i then
i
i i
def
m
concrete X fc j c Concrete
G G
c primary X c primary X
G G G G n
c concrete X c c c c
G G
C C C A A A A g
i c G c c c c i
i i
otherwise
def
concrete X
G
where C A abstract c and C A abstract c
c c G c c G
Informally a concrete set is a set of concrete constructor pro ducts c that are the maximal
ones b elow all of the typ es X Maximality here is understo o d in the following sense c dominates
i
c in the concrete set if it is ab ove c and its abstract form whichisatyp e X has the prop erty
c
X X glb X where X is the abstract form of c
c i
c i c
Consider the following example Let the following b e the sp eci cations given in the program
type T Ordered contravar X
type T Numeric subtype of T Ordered T Numeric
concrete type T Char subtype of T Ordered T Char
concrete type T Real subtype of T Numeric
concrete type T Integer subtype of T Real
and the constrained typ es X and X given by
X T Ordered
X T Integer T Ordered
The primary form of X is
Ordered T Orderedi hT
while the primary form of X is
hT Integer T Orderedi
The concrete set for X is
Real T Reali hT Real T Chari hT Char T Reali hT Char T Charig fhT
and for X as well for X X
fhT Integer T Reali hT Integer T Charig
Another example that shows how the last condition in De nition works is given b elow
type T A
type T A
type T B
type X T A T C covar X
T C X T B
type X T A T C covar X
T C X T C X
The concrete set for the typ e T B will b e fT C T C g In order to see why T C is in this set even
though it is b elow T C we write the elimination condition from De nition here c T C and
c T C
A T A T C T C T C T B T
G
This is not true e g take T A and the left hand side b ecomes unsatis able as it implies
A T A which is not the case Therefore T C can not b e eliminated from the concrete set for T
T B even though T C is b elow T C in the graph Informally it is not eliminated b ecause there are
typ es of the form T C that are subtyp es of T B but not subtyp es of any of the typ es T C
The b ehavior coverage condition ensures that for every b ehavior de nition and for every concrete
pro duct that satis es its conditions there is at least one asso ciation for this b ehavior that has its
conditions satis ed by the same concrete pro duct Informally it means that every b ehavior de nition
is covered by at least one b ehavior asso ciation
De nition Behavior coverage A b ehavior b satis es coverage condition i
d d
i N t concrete C A j N
d G a
i i
d d a d a
C C fA A g fA A A g C
t t G t
i i j i j
where C A abstract t
t t G
d d d
behavior C A R i N
d
i i i
are the b ehavior de nitions for b and
a a a
association C A R i N
a
i i i
are the b ehavior asso ciations for b
Consider the following example Let the following b e the sp eci cations given in the program
type T Ordered contravar X
type T Numeric subtype of T Ordered T Numeric
concrete type T Char subtype of T Ordered T Char
concrete type T Real subtype of T Numeric
concrete type T Integer subtype of T Real
behavior T Ordered X T Ordered X T Boolean compare
association T Char T Char T Boolean compare implementation fun
association T Real T Real T Boolean compare implementation fun
Then according to the de nition wehave to nd an appropriate asso ciation for eachtyp e in the
Ordered T Ordered using for the free typ e variable X concrete set of the typ e X T
The concrete set is
fhT Real T Reali hT Real T Chari hT Char T Reali hT Char T Charig
Real T Reali and the second asso ciation the condition is For the constructor pro duct hT
T Real T Real T Ordered T Ordered
G
T Real T Real T Ordered T Ordered T Ordered T Ordered
and is immediately satis ed For the constructor pro duct h T Char T Chari and the rst asso ciation
the condition is
Char T Char T Ordered T Ordered T
G
T Char T Char T Ordered T Ordered T Ordered T Ordered
For the constructor pro duct hT Real T Chari and the rst asso ciation the condition is
T Real T Char T Ordered T Ordered
G
Char T Char T Ordered T Ordered T Ordered T Ordered T
which is satis ed since
Real T Char T Ordered T Ordered T
T Numeric T Char
Char T Char T Ordered T Ordered T
The conditions for the constructor pro duct hT Char T Reali are satis ed in the same way
Thus there is at least one asso ciation covering each constructor pro duct in the concrete set
and therefore the coverage condition for the ab ove sp eci cation is satis ed Note that wewere
able to con rm coverage even though there is no asso ciation for h T Numeric T Numerici since this
constructor pro duct is abstract and therefore do es not need to b e covered
The next condition guarantees that there is only one most sp eci c asso ciation for each concrete
typ e This in turn guarantees the absence of message ambiguous errors at run time This condition
is standard for the systems with multiple dispatch and is formulated in terms of constructor pro ducts
not typ es
De nition Behavior unambiguity Abehavior b satis es unambiguity condition i
i j N
a
a a a a a a a a
primary C A primary C A primary C A primary C A
G G G G G G
i i j j j j i i
a a a a
t concrete C A C A
G
i i j j
a a
k N t primary C A
a G G
k k
a a a a
primary C A primary C A
G G G
k k i i
a a a a
primary C A primary C A
G G G
k k j j
where C A abstract t and
t t G
a a a
association C A R i N
a
i i i
are the b ehavior asso ciations for b
The correctness condition is designed to check whether all typ e correct b ehavior applications of
a particular b ehavior are dispatched to a function that was typ e checked in accordance with the
actual argumenttyp es This condition is necessary b ecause dispatch o ccurs at a coarser granularity
than do es typ e sp eci cation All b ehaviors in the system are required to satisfy this condition
De nition Behavior correctness A b ehavior b satis es correctness condition i
a a a a
A primary C A i j N primary C
G G a G
j j i i
a a a a
t concrete C A abstract primary C A
G G G
j j i i
a a a a a
C C fA A g C fA A A g
t t G t
j j i i j
where C A abstract t and
t t G
a a a
association C A R i N
a
i i i
are the b ehavior asso ciations for b
Consider the following set of sp eci cations
concrete type T Set covar X
concrete type T SpecialSet covar X subtype of T Set X
association T Set X T Boolean isEmpty fun
association X T Person T SpecialSet X T Boolean isEmpty fun
The second function is only supp osed to b e invoked for sp ecial sets of p ersons or their subtyp es
However since dispatch uses only primary functors of argumenttyp es it is unable to distinguish
SpecialSet T Person andT SpecialSet T Object and dispatches to the second func between T
tion as the more sp eci c one in b oth cases This causes the b o dy of the second function to b e
executed under more lib eral assumptions then the ones used when its b o dy was typ echecked and can
therefore cause run time typ e errors Therefore the ab ove set of sp eci cations is disallowed Indeed
the b ehavior correctness condition in this case is for the typ e constructor T SpecialSet whichis
in the concrete set of T Set T SpecialSet
SpecialSet T Set T
G
Person T SpecialSet T SpecialSet T Set T
which is equivalentto
TRUE T Person
G
Person do es not hold and is false as there exists an such that T
De nition Dispatch The function dispatch b q B RTyp N is de ned as
G G a
follows
b b
i s h s ii S t if jS t j
def
min min
dispatch b q
G
otherwise
where B is the set of all b ehaviors
def
t primary q
G
def
b a a
S t fhs iijs primary C A t sg
G G
i i
def
b b b
t fhs iijhs ii S t hs i i S t s sg S
G
min
and
a a a
association C A R i N
a
i i i
are the b ehavior asso ciations for b
In this de nition the notion of run time type De nition domain RTyp has b een used
G
along with the appropriate extension of primary given in De nition Intuitively a run time
G
typ e is a typ e of an ob ject that is present during program execution Every run time typ e is also
atyp e but the opp osite is not true For example an abstract typ e is not a run time typ e b ecause
an ob ject of suchatyp e can never b e created and thus can not b e present at run time Some other
restictions also apply
The dispatch pro cess cho oses the most sp eci c asso ciation with resp ect to the typ e
that is obtained by taking the argument typ e and cutting o its leaves For ex
ample the typ e T Collection T Person b ecomes T Collection while the pro duct typ e
T Collection T Person T Integer b ecomes hT Collection T Integeri If the most sp eci c
asso ciation do es not exist either there are no suitable asso ciations or there are several suitable
asso ciations that are incomparable to each other then the dispatch fails and returns This can
never happ en in a successfully typ echecked program as will b e proven in Chapter
In this section the notion of dispatch consistency was intro duced The algorithms testing various
asp ects of dispatch consistency were presented and illustrated by examples
The next section intro duces the core algorithm of the presented typ e system
Entailment
The algorithms and notions presented in this section constitute the core of the presented consistency
checking algorithms The algorithms of this section always deal with expanded typ es and constraints
W W
can b e understo o d as a logical formula C C The entailment relationship
j i
j i
C C
i j
i j
where
FTV C n FTV C
i j
i j
and FTV C The task of the main entailment algorithm is to determine whether a logical
j
j
formula of this form is satis ed in a typ e system de ned by the given user typ e graph G
W W
C C b e the entailment that is necessary Algorithm Deciding entailment Let
G
i j
i j
to check The algorithm op erates as follows
W
For each i check C C in the following manner
G
i j
j
a Check whether C as follows attempt to atten C w r t G If it fails the formula
G
i i
C can not b e proven and the algorithm ends with success a contradiction implies
G
i
everything otherwise continue to the next step
b Change all variables FTV C into ary typ e constructors a Form the extended
k k
i
i
typ e graph G by adding edges corresp onding to constraints from C and vertices corre
e
i
sp onding to typ e constructors a to G
k
i
c If G do es not haveavalid ranking end the algorithm with the result UNKNOWN
e
i
a w r t G If at least one of them succeeds succeed d For each j attempt to atten C
e
j
otherwise fail
If all checks ab ove succeed succeed otherwise fail
For example in order to check the entailment
the entailment is checked rst Since the formula on the right of the turnstyle is
already attened the check succeeds and the algorithm pro ceeds to the next step Here the typ es
a b and g are intro duced into the typ e graph G with the following relationships b etween them
e
a b b g
G thus obtained has a valid ranking and the algorithm now attempts to prove
e
a g
G
e
by attening the formula a g w r t G The attening succeeds and therefore the algorithm
e
nishes with success
Algorithm Flatten Let C is the constraint formula to b e attened
Initialization
Create an initially empty set D of already checked constraints
Create an initially empty set E of eliminated variables
For eachvariable create initially empty sets of lower and upp er b ounds L and U
i i i
Create a directed graph G with vertices and initially no edges
i
Create a list of complex constraints C Set C to C arbitrarily ordered
Pro cess For each constraint A B in C do
Remove the constraint from C
Clear the set of new constraints N
If A B or A B D continue to the next constraint
Otherwise add the constrainttoD and do the following
a If A B and there is no path from to in G then do the following
i j i j
i Add the edge to G
i j
ii If the addition of the edge creates cycles in G replace all variables
i i
n
involved in the cycles in all expressions used in the algorithm by the variable
i
Collapse vertices into the single vertex in G New sets U and
i i i
n i
L for this vertex are constucted as follows U U and L U
j i j i
j j
i i i
For eachpairhl ui L U add the constraint l u to N Add the set
i i
n
f g to E
i i
k
k
iii Otherwise no cycles form sets
S L where k fk j there is a path from to in Gg
l k k k i
S U where m fm j there is a path from to in Gg
u m m j m
For eachpairhl ui S S add the constraint l u to N
l u
b Otherwise if A lub A add constraints of the form A B to N
i i i
c Otherwise if B glb B add constraints of the form A B to N
i i
i
d Otherwise if A add B to the set U Form the set
i i
S L where k fk j there is a path from to in Gg
l k k k i
Add constraints of the form l B l S toN
l
e Otherwise if B add A to the set L Form the set
i i
S U where k fk j there is a path from to in Gg
u k k i k
Add constraints of the form A u u U toN
k
Var a i
f Otherwise if A a A andB a B add the constraints A B to N Here
i i
Var a i f g is the de ned variance of the i th parameter of typ e constructor
a and addition of a constraint A B is
treated as addition of two constraints A B and B A
g Add constraints in N n C D to the tail of C
h If the current constraintwas not pro cessed on this step remove it from D and put
it backinto the head of C so that the algorithm do es not try to pro cess it now
Resolution Empty the set of sets T For each constraint A B in C do
Remove the constraint from C and add it to D
If A glb A add the set fA B g to T
i i
i
Otherwise if B lub B add the set fA B g to T
i i i
Otherwise A a A and B b B Do the following
i i
a If there is no path from a to b in G fail
b Otherwise for each path P ha c c c bi from a to b in G addC to set
n
T HereC is the set of the following constraints
Var c i
A C
i
i
C C
C C
C C
Var c i
C C
i
C C
C C
C C
Var c i
C C
i
n n
C B
i
i
where
k k k k k k
c C C c C
k k
are the lab els of the edges in P and
k
type C c V
k c i
k
are the lab els of vertices in P All new variables intro duced on this step are considered
to b e fresh
Subgoals Create a cross pro duct of all sets in T T t Empty the result set R For each
t T
t T do
Clone the state of the algorithm G G FTV t D D U U L L C C t
i i
i i
E The lower and upp er b ounds sets for the variables in FTV t n vertices G are
set to empty sets
Solve the resulting task starting from the step Pro cess
If there was a success add the result to R
If none of the tasks ab ove succeeds fail
Finalization If C is empty succeed the attened form is
r l u e
i i i j
r R i u U e E
l L
G
i
i
i j
Otherwise continue from step Pro cess
Example Consider the following sp eci cation
type T Set covar X
type T List novar X
T List X T Set X
and the formula T List T Set
Initialization D L L U U vertices G f g C
fT List T Set g
Pro cess Skip as the rst and only condition in C do es not have the form suitable for pro cessing at
this step
Resolution T Since the constraint has the form T List A T Set B andthereisapath
from T List to T Set in G the following conditions form the set C
C f g f g
where is a fresh variable Now T T C C
List T Set g C C nfT
and
List T Set g fT List T Set g D D fT
Subgoals R the new subtask is formed
G G D D U U i f g L L i f g
i i
i i
L U C C T f g
Subgoal
Pro cess Pro cessing the rst constraint c adding edge to G removing c from
C inserting c in D
Pro cess Pro cessing the second constraint c an attempt to add the edge to G
leads to a cycle Collapsing and to Removing c from C inserting c in D adding
f g to E
Pro cess Pro cessing the second constraint c note that due to the change made in
the previous step the variable on the left was changed from to adding the edge
to G
Finalization Skipping to nalization since C is empty The result is
The subgoal is achieved returning one level back
There was a success R R f g f g
Finalization Set C is empty succeed with the result
List T Set inthegiven typ e system was found to b e Thus the attened form of T
F Since is a fresh variable which is not used anywhere else F is equivalentto
In this section the core entailment attening algorithm was presented A simple example was
used to illustrate the algorithm
Conclusions
In this chapter the typ echecking algorithm for the prop osed typ e system has b een presented The
algorithm works in several stages First the source language program is translated to a simpli
ed target language Second the target language program is analyzed and typ echecked During
typ echecking several asp ects of program consistency are veri ed For asp ects related to dispatch a
separate algorithm is used The algorithm describ ed in Section is a generalization of algorithms
develop ed in ADL Ghe MHH BSG Cas b CGL CL CL QKB Sha
The core of the rest of the typ echecking system is the entailment attening algorithm presented
in Section which is a generalization of algorithms presented in BM b and Pot
In the next chapter the formal asp ects of the typ e system presented so far will b e discussed
Chapter
The Typ e System Theory
The set of rules and algorithms describ ed in the previous chapter de nes a pro cedure for typ echecking
a program in the target language As with anytyp e system two main questions arise
Do es the typ echecking algorithm always terminate decidability
If a program is successfully typ echecked do es it guarantee the absence of typ e errors at run
time correctness
In this chapter b oth of these questions will b e answered It will b e proven that the typ e system
presented in this dissertation is b oth decidable and correct Decidability of the algorithms will b e
discussed in Section
Section presents a theoretical framework for reasoning ab out typ es It will b e proven that
the core entailment algorithms give correct results with resp ect to this framework
In Section the natural semantics of the target language is presented Using the framework
established in the previous section the sub ject reduction theorem for the given semantics of the tar
get language will b e proven This will establish correctness of the typ echecking algorithms presented
in the previous chapter
Section describ es intro duction of imp erativetyp es in the typ e framework established so far
gives semantics to the ob jects of these typ es and proves that the correctness of the typ echecking
is not a ected by the intro duction of suchtyp es This section serves a dual purp ose First it
demonstrates howthetyp e theoretical framework established so far can b e extended to deal with
typ es not present in the basic typ e set of the framework Second it shows that the addition of
imp erativetyp es to the target language do es not a ect any asp ects of the typ echecking including
algorithms and the correctness results
Section discusses various p ossible extensions to the natural semantics and its handling by the
typ e system While the primary purp ose of this chapter is to develop and presentthetyp e system
theory rather than an ob ject oriented language semantics it is imp ortant to address the typing
issues that might arise during the development of the full edged version of suchsemantics
In Section various features of the presented theory are discussed and the main results of this
chapter are summarized
Decidability
In this section decidability of Algorithms and will b e proven All the other algorithms in
Chapter are trivially terminating as they are either non recursive or their recursion is based on
the structure of a given nite expression
The decidability pro ofs in this section are based on Lemma that will b e proven in the following
section
Finite evolution
De nition Evolution system The evolution system E isatuplehE R I r E R S i
where E is a set elements of this set will b e called e atoms R is a totally ordered set of ranks r
is a ranking function that assigns a rank from R to each elementofE r e r I is a nite set
e
of indices and S is the initial state S is a nite subset of E S E
The evolution process is a pro cess of transforming the state of the evolution system
hS S S i
It consists of evolution steps which transform the current state of the system S into its next state
k
S
k
Eachevolution step consists of zero or more repro ductions and exactly one survival where
repro ductions and survival are de ned b elow
Individual Repro duction A single e atom parent e is chosen from S and a single index i is
k
N
chosen from I Their pairing he ii results in one or more children fc g such that
i
i
maxfr c g r e
i
i
The set of children is added to S
k
Paired Repro duction Two e atoms parents e e are chosen from S Their combination results
k
N
in one or more children fc g suchthat
i
i
maxfr c g minfr e r e g
i
i
The set of children is added to S
k
Survival A subset of surviving e atoms S is chosen from S S S and added to S
k k k
In addition eachevolution pro cess has the following prop erty
During an evolution pro cess each pair
ho o i E E E I
can participate in repro duction no more than once Here
def
A B A B B A
An evolution system can b e thought of as a system of living creatures that evolve in discrete
time These creatures p ossess some genetic prop erty rank that diminishes after each repro duction
Since eachevolution step must decrease the ranking there can b e a state in which the system can
no longer evolve If all strictly decreasing sequences in R are nite it is intuitively obvious that any
evolution system will eventually in a nite numb er of steps come to the p oint when the evolution
stops This intuitive observation is supp orted by Lemma The following de nition gives precise
meaning to the notion of a downward nite set whichisintuitively equivalent to an ordered set with
no in nitely decreasing sequences
De nition Downward nite set Aset E is downward nite if
E is totally ordered
There are no decreasing in nite sequences in E i e there are no sets e i e E
i i
such that the following holds i j e e
i j
For example the set of natural numb ers is downward nite while the set of all real numb ers
between and is not
Lemma Finite evolution If E hE R I r E R S i is an evolution system and the
rank set R is downward nite then
the number of evolution steps involving repro duction is nite
the union of all states of anygiven evolution pro cess contains a nite numb er of e atoms
if E is such that there can b e no in nite sequence of survival only steps then there is no in nite
evolution pro cess for E i e eachevolution pro cess contains a nite numberofsteps
Proof The second statement of the lemma follows from the rst one the niteness of the initial
state and the fact that eachevolution step adds no more than a nite numb er of e atoms
The third statement of the lemma also trivially follows from the rst one
Thus it is su cienttoprove the rst statement The pro of will pro ceed by constructing a series
of nite sets U and T suchthat
k k
S U
k k
U U T
k k k
T T
k k
T maxfr e j e T g maxfr e j e T g
k k k
Once such sets are constructed the following reasoning is used Let
r max fr e j e T g
k k
Then r r and since R is downward nite
k k
N i N T
i
and therefore
i N U U
i N
thus
i S U
i N
from which
i S S S I U U U I U
i i i N N N
U is nite since U and I are nite Eachevolution step uses up at least one pair from U
N
Therefore there can b e no more than K repro duction steps where K is the cardinalityof U Thus
the total numb er of repro ductiveevolution steps is nite
In order to complete the pro of it is su cienttoshow that the series of sets T and U satisfying
k k
the conditions can b e constructed for anygiven evolution pro cess
Assume P hS S i is an evolution pro cess for the evolution system E Construct sets T
i
and U in the following way
i
U S
U U T
k k k
T S
S
T C o o
k
h o o i T U T I
k k k
where C o o is the set of children that was pro duced when the pair ho o i was used in re
pro duction during the evolution pro cess P If the pair was never used C o o C o o
is well de ned since each pair can b e used no more than once during a given evolution pro cess
according to the de nition of the evolution system
Now itwillbeshown that the sets constructed ab ove satisfy the conditions
Condition First an auxiliary statement will b e proven It will b e shown that
C o o U
k
h o o i U U U I
k k k
Pro of by induction
Base k
C o o
h o o i U U U I
C o o
ho o i S S S I
T U T U
Induction Assumption
C o o U
k
ho o i U U U I
k k k
Then
C o o
ho o i U U U I
k k k
C o o
h o o i U U U T T T U I T I
k k k k k k k k
C o o
h o o i U U U I
k k k
C o o
h o o i U T T T U I T I
k k k k k k
U C o o
k
ho o i U T T T U I T I
k k k k k k
U C o o
k
ho o i U T T T I
k k k k
U T U
k k k
Nowitispossibletoshow that the condition is satis ed The pro of is again by induction
Base k S S U
Induction Assumption S U Let P b e the set of parent pairs of repro ductions at
k k k
the k st step and C o o bethesetofchildren pro duced by the pair ho o i
k
at the k st step Then C o o C o o and
k
P S S S I
k k k k
Thus
S S C o o n S
k k k
k
ho o i P
k
S C o o n S
k
k
ho o i P
k
C o o S
k
ho o i P
k
U C o o
k
ho o i P
k
C o o U
k
ho o i S S S I
k k k
C o o U
k
ho o i U U U I
k k k
U U U
k k k
Condition Immediate from de nition of U
k
Condition Immediate from de nition of T
k
Condition By de nition of repro duction
maxfr c j c C o o g minfr o r o g
Therefore provided T and T
k k
maxfr o j o T g
k
max fr o j o C o o g maxfr o j o T g
k
ho o i T U T I
k k k
Thus it has b een shown that a sequence of sets U and T satisfying the conditions
k k
can b e constructed for anyevolution pro cess Therefore the lemma has b een proven
Termination of expansion algorithm
Algorithm is used to nd an expanded form for a given simple constrained typ e C A w r t the
given user typ e graph G The following theorem establishes the termination of this algorithm for
any constrained typ e provided G has valid ranking see De nition
Theorem Termination of expansion algorithm Algorithm terminates for any con
strained typ e C A provided G has a valid ranking
Proof Letr beavalid ranking in G De ne ranking r foreachtyp e A that is not a typ e variable
or a ary constructor as r r pfunctor A The rank set will b e a set of natural numb ers less
or equal to the maximum rank inr The set S used in Algorithm is an evolution system and
each iteration of the algorithm is its repro duction step Therefore according to Lemma the
algorithm terminates for any simple constrained typ e C A
Termination of attening algorithm
Algorithm is used to nd a attened form for a given constraintsetC w r t the given user typ e
graph G The following theorem establishes the termination of this algorithm for any nite constraint
set provided G has valid ranking see De nition
Theorem Termination of attening algorithm Algorithm terminates for any nite
constraintset C provided G has a valid ranking
Proof First the niteness of the step Pro cess will b e demonstrated The step Pro cess isacycle
that adds new constraints to the list of constraints C it iterates over it only passes through newly
added constraints that were added to the tail of the list It also mo di es the graph G and the sets
U and L of upp er and lower b ounds for each participating variable For each constraintthatis
i i
added to the tail of the list the algorithm checks whether this constraint has already b een pro cessed
pro cessed constraints are stored in set D Consider the set W of all typ e expressions participating
in constraints in C U L Assume the initial set C is nite Then W is nite as well
i i i i
and therefore there is only a nite numb er of p ossible constraints w w suchthatw and w
l u l u
are sub expressions of some typ e expressions from W Such constraints constitute a nite set X
The algorithm for the step Pro cess never creates new expressions it only decomp oses the typ e
expressions in W to pro duce new constraints Thus
One constraint is eliminated from the remainder of C on every iteration
Every constraintinC is pro cessed no more then once due to the usage of the set of already
pro cessed constraints D
Constraints that are added to the remainder tail of C are taken from the nite set X
The set X is the cycle invariant
Therefore the iteration must stop no later than on its x th step where x is the cardinalityofX
Thus the niteness of the step Pro cess is proven
Next the niteness of the whole algorithm will b e shown First a ranking of typ e expressions will
be intro duced This ranking will later b e used to de ne an evolution system related to the algorithm
Lemma will then b e applied to the resolution system to yield the algorithm termination
Letr beavalid ranking in G Let N i bethenumber of typ e constructors c in G suchthat
r c i To eachtyp e constructor c assign a number M c in the range N r c insuchaway
that
c d r c r d M c M d
De ne a new ranking
P
r a min r c
c G
M a j N j a is a typ e constructor
j
def
r a
a glb
a lub
This new ranking has two prop erties
It is a valid ranking since it do es not change relative ordering of constructor ranks i e
r a r b r a r b
It assigns a unique number to each non ary typ e constructor in G as wellastotyp e op erators
lub and glb
Letr b e the maximum rank in this new ranking De ne a simpli edtreerepresentation of a
max
typ e as its tree representation stripp ed o ary typ e constructors and de ne ranking r for each
typ e A as a tuple hn n i where n is the maximum heightofthevertices corresp onding to
r i
max
the typ e constructor a with the rankr a i in the simpli ed tree representation of typ e A or zero
i i
if the constructor a do es not participate in A For example ifr a r b and r c
i
thenr a a b b h i r a c h i and r h i Let
the tuples b e lexicographically ordered Then the set of such tuples comprises the ranking set R
whichisdownward nite
Let I b e the nite set of ary typ e constructors in G Let the connector set of typ e expressions
A a A and B b B along the path P ha c c c bi in G be the set N A B P
n
de ned as follows
fA gnI N A B P
i
fC gnI N A B P
i
all typ e expressions in C C n I N A B P
all typ e expressions in C C n I N A B P
all typ e expressions in C C n I N A B P
fC gnI N A B P
i
fC gnI N A B P
all typ e expressions in C C n I N A B P
all typ e expressions in C C n I N A B P
all typ e expressions in C C n I N A B P
gnI N A B P fC
i
fC gnI N A B P
n n
fC gnI N A B P
i
fB gnI N A B P
i
where
k k k k k k
C c C c C
k k
are the lab els of the edges in P and
k
type C c V
k c i
k
are the lab els of vertices in P All new variables intro duced here are considered to b e fresh
From the de nition of valid ranking the de nition of r above and the de nition of connector
set it follows that
fA B gnI minfr t j t fA B gnI g maxfr t j t N A B P g
for anypath P from a to b
Each Resolution step either completes the given branch of the algorithm or creates several
new branches In order to show the algorithm termination it is su cient to demonstrate that all
branches terminate Consider any single branch Consider the sets
n I S all t yp e expressions in T
i
i
for T that o ccur on i th step in the branch under consideration Each step of the algorithm either
i
adds one or more of the following to S to pro duce S or terminates its branch
i i
If lub w w S addfw gnI to S
i i i i i
If glb w w S add fw gnI to S
i i i i
i
If a A A S i I and P is a path from a to i in G addN A i P to S
i i
If a A A S i I and P is a path from i to a in G addN i A P to S
i i
If a A A S b B B S and P is a path from a to b in G addN A B P toS
i i i
Thus each transition from S to S is a repro duction step of the evolution system E
i i
hE R I r S i where E is the set of all p ossible typ e expressions Repro duction steps never
rep eat in a single branch due to the presence of the set of already pro cessed constraints D There
fore the conditions of Lemma are satis ed and the branch under consideration terminates Due
to the arbitrary choice of the branch this proves the algorithm termination
Termination of entailment algorithm
Algorithm is used to decide entailmentontyp e constraint sets It transforms the task of deciding
entailmentinto the question of p ossibility of attening The transformation is done by creating a new
user typ e graph that is obtained from the original one by adding certain vertices and edges to it Since
attening algorithm terminates whenever the user typ e graph has a valid ranking Theorem and
Algorithm always checks whether a newly generated graph has a valid ranking b efore it makes
an attempt to atten against it the following theorem has b een proven
Theorem Terminationofentailment algorithm If the graph G has a valid ranking then
Algorithm terminates
Thus the termination of all non trivial algorithms describ ed in Chapter has b een proven The
next section formally intro duces the notions related to typ es and typ e constraints and applies them
to establish correctness prop erties of the main algorithms These prop erties will b e used in the pro of
of sub ject reduction theorem in Section
Typ es
In this section the basic notions of the typ e system theory will b e formally de ned These notions
are
Ground typ es represented as regular trees over a nite alphab et a set of typ e constructors
These will b e intro duced in Section
Subtyping de ned as a partial pre order on the domain of ground typ es Subtyping is de ned
in Section
Entailment as a relationship b etween sets of subtyping constraints will b e intro duced in Sec
tion
Constrained typ es that denote certain sets over the domain of ground typ es will b e de ned
in Section The notion of subtyping as well as other notions presented so far will b e
extended to deal with constrained typ es
In Section these notions will b e used to prove that the entailment and attening algorithms
of Chapter are correct with resp ect to the regular tree mo del develop ed so far The attening
algorithm is also proven to b e complete
Regular trees
The mo del that is used for typ e theory develop ed in this dissertation is the mo del of regular trees
de ned b elow
De nition Regular trees Let L b e a nite ranked alphab et L fa g with a total
i i
ranking function Arity L N f g Then a tree over L is a partial function N L from
sequences of natural numbers into elements of L that satis es the following conditions
hi dom where hi denotes the empty sequence
If a then j is de ned for all j f Arity a g and unde ned for all
i i
j Arity a
i
If j is de ned then is also de ned
A subtree of a tree at where exists is de ned as
def
A regular tree is a tree that has a nite numb er of subtrees The domain of all regular trees over L
is denoted Tree L A regular tree that has an additional prop erty that
N N j j N is unde ned
is called a nite tree The domain of all nite trees over L is denoted as Tree L
n
De nition Contractive regular system of equations Let L b e a ranked alphab et and
TyVar b e a set of ary type variables TyVar L Then
e
i i n
where TyVar e Tree L f g is called a regular system of equations
i i n n
n
over Tree L If in addition to the ab ove e TyVar for all i then is called a
i n
contractive regular system of equations A tuple ht t i is called a solution of i
n
t e t t
i i n n
where
a if and e
def
e a
e otherwise
Algebraic and top ological prop erties of the domain Tree L have b een studied in AN and
Cou Prop erties of systems of contractive regular equations over such domains have b een inves
tigated in Cou Regular trees were also used to mo del recursivetyp es in AC The following
result from the ab ovementioned pap ers will b e used later in this chapter
Theorem Contractive regular system solution If E is a contractive regular system of
equations over Tree L then E has a unique solution in Tree L
In AC it is also shown that Tree L is isomorphic to the domain of nite ground types fgt
n
de ned by the grammar
fgt a fgt fgt
Arity a
where a L while the domain of recursive ground types rgt de ned by the grammar
rgt ja rgt rgt j rgt
Arity a
where TyVar a L is a sub domain of Tree L From now on the ab ove relationships b etween
tree and typ e domains will b e used to give meaning to the usage of typ es in contexts requiring trees
and vise versa
Subtyping
This section de nes subtyping as a partial pre order over the domain of ground pre typ es which
are regular trees satisfying certain conditions Subtyping is de ned with resp ect to the typegraph
that is given by the set of constructors their arities and variances and subtyping relationships
between them These subtyping relationships are expressed as constraint systems that are de ned
b elow This way of de ning subtyping relations is due to Pot but is generalized here to allow
signi cantly more exibility in the de nition of the basic typ e system
De nition Constraint system Let L be a ranked alphab et and TyVar b e a set of ary
tree variables TyVar L Then
e e
n i n
i
i
where TyVar e Tree L f g is called a constraint system over
i i n n
n
Tree L denoted C An empty constraint system with free variables is denoted
n
TRUE
n
For example b oth TRUE and c a are constraint systems
De nition Constraint formula A logical formula F built with logical connectives and
is called aconstraint formula over L i every atom in F has one of the forms
e e
n i n
i
or
TRUE
n
or
FALSE
n
where TyVar and e Tree L f g
i i n n
n
Each constraint system is a constraintformula Moreover each constraintformula can b e repre
sented in the form C where eachofC is a constraint system
i i i
The satis ability of a constraintformula system can only b e de ned with resp ect to the se
mantics of a given subtyping relationship de ned b elow
De nition Typ e graph A typegraph G is a directed acyclic graph with vertices from a
ranked alphab et L L G with ranking function Arity and marked edges together with variance
function Var L N f g suchthatVar a i is de ned for all i from to Arity a Edges
of the graph a a are marked with constraint systems C over L such that
FTV C f g
Arity a
Arity a
The following de nes ground pre typ es as regular trees with no in nite sequences of b ound
op erators lub and glb
De nition Ground pre typ es If G is a typ e graph then the domain of ground pre types
PreTyp G over G is de ned as the domain of regular trees over L G fglb lubg where Arity glb
Arity lub restricted b y the following condition if is a pre typ e and fj g is an in nite
i
i
sequence such that i hj j i dom then n i n h j j i L
i i
The last condition is designed to eliminate the nonsense trees like
lub lub lub lub lub
Subtyping is de ned b elow as a binary relation on ground pre typ es It is de ned as the limit of
the in nite series of decreasing relations These relations are de ned recursively
n
b elow
De nition k subtyping k subtyping for k N f g is a binary relationship over
PreTyp G PreTyp G denoted de ned recursively as follows
k
subtyping for all
V
def
Arity a
a
f Structural a a
k i
Arity a
Arity a i
i
i
if Var a i
k
a
where a L G and f
if Var a i
k
i
if Var a i
k k
Constructors
a a
k
Arity
a
Arity a
jpj
def
p
C
n k n
p p
i
p
i
a p ha a a a ai is a path from a to a in G with edges lab eled with where a
jpj
jpj
p p p
is de ned as j andC FTV C i jpj n j C
p
i i i i
Case i
Arity a
def
p
a
C f
j j
j
j
Case i jpj
Arity a
def
p
a
i i
i
f C
j j
j i
j
p
i i i i
C
Arity a
i Arity a j
i Arity a
Arity a
i
i
i
jpj
i
i
and where and i jpj are fresh typ e variables
i
j
j
i
Lub
def
lub
k k k
and
def
lub
k k k
Glb
def
glb
k k k
and
def
glb
k k k
The series is a decreasing sequence of symmetric and transitive relations on PreTyp G
k
This fact immediately follows from case analysis of De nition
De nition Subtyping Subtyping is a binary relation over PreTyp G PreTyp G de
noted de ned as
def
k
k
Subtyping is a symmetric and transitive relationship on PreTyp G
De nition de nes a generalization of the traditional notion of subtyping of recursivetyp e
trees for the case of variance annotated non structural graph G with conditional subtyping
De nition do es not state that subtyping should b e a partial order it is only required to
b e a pre order Indeed lub a a a and a lub a a while a lub a a as trees Given a typ e
def
graph G the domain of typ es Typ G is de ned as PreTyp G where
From now on equality will b e used to denote the relationship just de ned
while equivalence will b e used to denote equalitybetween and as regular trees
The equivalence classes of ground pre typ es will b e called ground types and will b e denoted with
aslight abuse of notation by their representatives For example b oth a and lub a a denote the
same ground typ e The subtyping relationship over PreTyp G induces partial order subtyping
over Typ G
Entailment
The entailment relationship b etween constraint systems intro duced in this section is central for the
presented typ e theory Entailment expresses the fact that one constraint system formula follows
from the other in the sense of rst order logic
and C are constraint De nition Entailment If C
N
N N
formulae over L G flub glbg then C implies C w r t G denoted C C i
G
PreTyp G C PreTyp G
N
N N N
C
N N
N N
For example
is a true statement since for any and suchthat and also holds Another
example of a true statementis
T Integer T Real
G
provided that T Integer T Real Indeed for any that is less than T Integer it is p ossible
G
to take which will automatically satisfy
T Real
An example of a false entailmentis
TRUE T Integer
since not every typ e is a subtyp e of T Integer Note however that T Integer is a true
statement as there exists an such that T Integer
The following are the prop erties of the entailment relationship de ned ab ove All of them trivially
follow from De nition
Re exivity C C for any constraint set C
G
False premises If C then C C for any C
G a a G b b
Right elimination If C C C then C C
a G b c a G b
Restricted transitivity If C C C and C C then C C C C provided that
a G b c c G d a G b c d
FTV C n FTV C FTV C FTV C
d c a b
The following lemma establishes the relationship b etween the constraints on the left hand side
of the turnstyle and the set of constraints implicit in the construction of the graph G
Lemma Extended graph entailment If G is a typ e graph C has a solution in PreTyp G
and C a has a solution in PreTyp G then C C where G is de ned as follows
i i e G e
G G
e
For every typ e variable FTV C there is a ary typ e constructor a G suchthat
i i e
a L G
i
For every constraint c T T inC there is an edge from pfunctor T a to
i i
pfunctor T a in G lab eled with c a
i i e i i
Proof Assume M is a solution of C in PreTyp G andM is a solution of C in PreTyp G It
e
will b e shown that M M M a M is a solution of C a in PreTyp G Once this
i i i i
is done the entailment C C will follow directly as it will follow that for any solution M of
G
C there exists a solution M of C suchthatM M In order to showthatM is a solution of
C a in PreTyp G it is su cienttoprovethat
i i e
t t t M a for all i t M a for all i
G i i G i i
e
for all t t PreTyp G Indeed if is satis ed then
e
C a M C a M M a M C M M a
i i i i i i i i
whichfollows from the fact that M is a solution of C in PreTyp G and from
e
The pro of of is by induction
Basis
t t M a for all i t M a for all i t
G i i G i i
e
is trivially satis ed since x y is true for all x and y
G
Induction step From k to k If
t t t M a for all i t M a for all i
G i i k G i i
e
then
t t M a for all i t M a for all i t
G i i k G i i
e
There are several p ossible cases
pfunctor t L G n L G In this case t t a and the subtyping is pfunctor t
e i
immediate for all k including k
pfunctor t pfunctor t L G According to the Structural clause of the subtyping
de nition
t M a for all i t M a for all i
i i k G i i
n
a
a G
f M a for all i
k i i i
i
i
i
where n Arity a t a t a and On the other hand
a n
a
n
a
t the following is true since t
G
e
n
a
a G
e
for all m f
i m
i
i
i
V
n
a G
a
and therefore by induction assumption for k M a for all i f
i i i k
i
i
i
pfunctor t pfunctor t fpfunctor t pfunctor t g L G According to the clause
e
Constructors of the subtyping de nition and to the assumption t t there exists a
G
e
path p from a pfunctor t toa pfunctor t inG such that jpj and
e
jpj
p
C
n G n
p e p
j
j
p
where C are de ned as in the de nition of subtyping This is equivalentto
j
jpj
p j j p j j
j
a f g a
p p
G
m e
j j
Arity a Arity a
j j
j
jpj jpj
p p
p
a t a t
p
G G
e e
Arity a
jpj
Arity a
jpj
p
j
PreTyp G and for each j a is a typ e constructor lo cated in j th p osition where
e
m
j
of the path p By induction assumption
jpj
p
C M a for all a
k G n i i i n
p p
j
j
In order to show it is su cient to demonstrate that
jp j
p j j p j j
j
f g a a
k G
m p p
j j
Arity a Arity a
j j
j
p
t a
k G
p
Arity a
jp j jp j
p
a t M a for all i
k G i i
p
jp j
Arity a
jp j
where p p L G This will b e done by separately considering each constraint Each
p p
in the path p Each a constraint in corresp onds to a single edge e a
j
j j
p p
in the path p which a constraint in corresp onds to a single edge e a
j
j j
corresp onds to a segment of the path p There are several p ossible cases
a e G In this case the constraint is immediately satis ed by
j
b e G fa a g L G By construction of G constraint C marking this edge
j j j e
in G has the following prop erties FTV C and C M a for all i istrue
e i i
p
From this assumption and the construction of C
j
p
C M a for all i
i i
k G
j
From the ab ove and the de nition of subtyping
p j j p j j
M a for all i a a
p p
i i k G
j j
Arity a Arity a
j j
c a L G a L G In this case consider the minimal segment s of the path p
j j
such that
e s
j
L G e s s a e
j j j
m m m
s a L G e s e
j j j
m m m
Let s have the length M Then all M vertices inside s are the additional
typ e constructors a and therefore do not b elong to p All constraints marking the
i
internal edges of s therefore have the form a a and are satis ed in
i
i
a a M a for all i
G i i i
i
by construction of the graph G and the solution M Since all additional constructors
e
p
are ary this also implies that C M a for all i for all internal edges
i i
k G
j
p
M a for all i is satis ed by Thus For the external edges C
i i
k G
j
j j p j p j
a a M a for all i
k G i i
p p
j j
Arity a Arity a
j j
p p
where a is the rst and a is the last constructor in s Therefore is satis ed
j j
pfunctor t g flub glbg Since the clauses Lub and Glb are Otherwise fpfunctor t
indep endent of the user typ e graph and the trees under consideration are in PreTyp G
e
the subtyping clause under consideration can b e equivalently formulated as
N
A A
j j
k G
j
where
fpfunctor A pfunctor A g flub glbg
j j
For each of these subtyping constraints holds by one of the previously considered
cases and therefore holds for this case as well
In this section the notion of entailmentwas intro duced and its prop erties were studied In the
following section correctness and completeness of the attening algorithm and the correctness of
the entailment algorithm will b e demonstrated
Prop erties of entailment and attening algorithms
Before the algorithm prop erties can b e established it is necessary to sp ecify how the user typ e graph
de ned by the program according to De nition can b e translated into the typ e graph de ned
and used in this section De nition
Let G b e a user typ e graph de ned by De nition The typ e graph G is constructed from
u
G as follows
u
For eachtyp e de nition in G there is a typ e constructor in L G and resp ectively avertex
u
in G with arity and variance de ned bythetyp e de nition
For each edge in G from a to a marked with constraints C there is a corresp onding edge in
u
G marked with C C C where C and C are constraints in typ e de nitions of a and a
a a
a a
resp ectively
G is then a typ e graph in terms of De nition
Theorem Correctness and completeness of Algorithm attening If G is the
u
user typ e graph G is its corresp onding typ e graph and C is a constraint system over G then
If F atten C then
G
a The set of solutions of C is the same as the set of solutions of F in PreTyp G
b Each disjunct in F has a solution in PreTyp G
If FAIL atten C then there is no solution to C in PreTyp G
G
Proof
Point a Follows from the de nition of subtyping and the algorithm by a simple induction on
all cases since each step of the algorithm replaces a constraintby an equivalent constraint
formula
Point b The formula F has the from
F l u
j j k m k m
i i i i
i j
G E
l L u U
k m k m
j j
where
i i
i j s L U s a a L G
j j
i i i
i j s L U FTV s vertices G
j j j
i
i G is acyclic
i n k n E
m m m m i
n k k
i i
FTV s f g
m m
U j s L
n
j j
It will b e shown that each disjunct in has a solution Let D b e a disjunct in
i
The presence of subformula
k m
i
E
k m
do es not change the set of solutions of D due to the condition Thus it is su cientto
demonstrate that
D l u
i i k m
i
l L u U G
i i k m
where
i s L U s a a L G
i i
i s L U FTV s vertices G
i i
G is acyclic
admits a solution
S
L and I fi j L g LetE b e the system of equations constructed Let L
j
i i
j
j G i
as follows
E f lub l j I g
i j i i
l L
i
It will b e shown that
E has a solution in PreTyp G
Any solution of E can b e extended to form a solution of D
S
e e e
L that i I s Let be Let S b e the set of all such sub expressions s of
i k
i
i I
e e
the set of fresh variables such that there is one variable for every sub expression s S Then
E can b e equivalently rewritten as
for all i I lub
k i k
i n i
E
for all k a
k k
k k
k
k Arity a
k
e
where a is the primary functor of the expression s that corresp onds to the variable The
k k
k
ab ove system of equations is regular and contractive and therefore by Theorem admits
a solution M M is a map from the set f g f g to the domain of regular trees over
i i I k k
L G flub glbg Lett b e the regular trees mapp ed to the variables by this solution Then
i i
they satisfy E since E and E are equivalent and therefore
t lub l t
i i i
l L
i
i I
S
Since l L L and D is a disjunct in the resulting formula pro duced by
j
i
j
j G i
Algorithm each l has the form a where a vertices G Thus
i i
t lub s s
i
n
i I
i i
where each s has the form a Therefore each path in t consists of a p ossibly in nite
i
j j
numberofsegments such that
The length of each segment is less then or equal to the maximum depth of typ e variable
i i
in the expression lub s s
n
i
Each segmentcontains at least one of a
j
Therefore by De nition t PreTyp G Since this argumentworks for all i
i
M fh t ig i t PreTyp G
i i i I i
is a solution for E
Nowitislefttoprovethat M can b e extended to a solution for D Let s form the map
M M fh ig This map is a variable assignment for all variables in D It will b e
i
i I
shown that M satis es all constraints in D
Constraints of the form l Since l L l L is true and therefore L thus
i i
i i
i I Therefore
l M for all k M for all k M t
k k i k k i i
lub l M for all k
k k
l L
i
which is true by de nition of subtyping for lub
Constraints of the form If i I then L L and therefore L j I
i j
i j j
Thus there are three p ossible cases
i I j I Then the constraint under consideration b ecomes whichis
trivially satis ed
i I j I Then the constraint under consideration b ecomes M whichis
j
trivially satis ed
i I j I Then the constraint under consideration b ecomes
M t lub l M for all k
i i k k
l L
i
l M for all k t M lub
k k j i
l L
j
whichistrueby the de nition of subtyping and the fact that L L
i j
Constraints of the form u There are two p ossible cases
i
i I Then the constraint under consideration b ecomes u M for all k
k k
which is trivially satis ed
i I The constraint under consideration b ecomes
l M for all k u M for all k M t lub
k k k k i i
l L
i
which is equivalentto
l M for all k u M for all k
k k k k
l L
i
Consider a single conjunct of the ab ove constraint
l M for all k u M for all k
k k k k
S
where l L L Sinceu U and the ab ove constraint is a part of
j i
i
j
j G i
the disjunct D pro duced by the nal step of the algorithm there must exist a step
Pro cess of the algorithm on which the constraint l u is pro duced and added to
N This implies that at some p oint of the algorithm execution the constraint l u is
in the set C Since l a andu a where a a L G and the algorithm
l u l u
has terminated the constraint had to b e pro cessed on the step Pro cess f if a
l
a or on step Resolution if a a The step Pro cess f is parallel to the
u l u
case Structural of the subtyping de nition and thus pro duces the constraint set C
such that every k solution of C is a k solution of l u The step Resolution
is parallel to the case Constructors of the subtyping de nition and therefore it also
pro duces the set of constraints C such that every k solution of C is a k solution
of l u Since each step of the algorithm pro duces equivalent constraint sets and all
steps of the algorithm except Resolution and Pro cess f pro duce k equivalent
constraint sets for all k the following statement is true
if M is a k solution of D itisak solution of l u and therefore since the
D
ab ove argumentworks for all l and i M is a k solution of all constraints of the
D
form u in D
i
Pro of by induction The solution M is a solution of D since is universal Assume M
is a k solution of D Then M is a k solution of all constraints of the form u in D
i
It has b een shown already that M is a solution of all the constraints other then those of the
form u Thus M is a k solution of all constraints in D all constraints except
i
by the statements already proven constraints by induction assumption Therefore M
is a solution of D for all k which is equivalent to the statementthat M is a solution of D
Thus it has b een shown that D has a solution in PreTyp G
Point Follows from p oint a and the de nition of subtyping as the algorithm only fails when an
unsatis able constraint is pro duced in all conjuncts of the resulting formula
Thus correctness and completeness of Algorithm have b een demonstrated
Theorem Correctness of Algorithm entailment If G is the user typ e graph G is
u
its corresp onding typ e graph and C C are constraint systems over G then
i j
W W W W
C C C C then If Algorithm succeeds on input
G G
i j i j
i j i j
Proof Assume Algorithm has succeeded It means that for each i one and only one of the
following is true
Algorithm fails while trying to atten C w r t G
i
Algorithm successfully attens C w r t G and also successfully attens at least one of C
i j
i
w r t G
e
In the rst case the constraint set C has no solutions by Theorem and can therefore b e
i
removed from the set of constraints on the left of the turnstyle without changing the truth value
W
of the entailment If this is the case for all i the constraintformula C has no solutions and
i
i
therefore the entailment is trivially satis ed Thus it is left to provethat
C C
G
i j
i j
under the assumption that for each i C has a solution in PreTyp G and there exists j suchthat
i
i
i
C has a solution in PreTyp G However the ab ove statementfollows directly from Lemma
j e
i
Theorem and the de nition of entailment
Note that while the attening algorithm is b oth correct and complete the entailment algorithm
is correct but not complete There are two reasons for the incompleteness First the extended typ e
graph pro duced by the algorithm at some p ointmight not haveavalid ranking In this case the
algorithm returns the UNKNOWN answer whichisinterpreted as FALSE bythetyp e system even
though the entailment might b e true Second the formula on the left hand side of the turnstyle is
not attened b efore the construction of the extended graph which leads to rejection of certain typ es
of correct formulae This is intentional as it makes this algorithm invarianttocovarianttyp e system
transformations whichplay a ma jor role in typ e system evolution see Section
Constrained typ es
In this section the theory of constrained typ es will b e develop ed Constrained typ es are sometimes
called type schemes e g in Pot
De nition Simple constrained pre typ e A simple constrainedpre type over a graph G
is de ned as
C A
n
where C is a constraint system over G FTV C f g and A is a typ e over
n
L G f g
n
The quanti cation part of the simple constrained pre typ e sp eci cation will often b e omitted in
cases when the context determines the set of variables b ound in the constrained typ e For example
t will often b e written as t
A simple constrained pre typ e can b e interpreted as the lower b ound of the set of ground typ es
that it denotes For example if t is a ground typ e then t and t are equivalent
De nition Constrained pre typ e A constrainedpre type X over a graph G is de ned as
follows
n
i i i i
X glb C A
i
i
n
i i i i
C A are simple constrained pre typ es where
i
n
Thus a constrained pre typ e is a greatest lower b ound of a nite numb er of simple constrained
pre typ es
De nition Subtyping of constrained pre typ es If
i i
X glb C A
i
j j
X glb C A
j
are constrained pre typ es the subtyping relationship b etween them is de ned as follows
def
j j
i i
X X j i C C A A
G
This subtyping relationship is transitive and re exive on the domain of constrained pre typ es
As with typ es the domain of constrained pre typ es is factored by the equality relationship de ned
as follows
def
X X X X X X
Thus each constrained pre typ e falls into one and only one equivalence class These equivalence
classes will b e called constrainedtypes Thesubtyping relationship de ned ab ove is a partial order
over the domain of constrained typ es Again byaslight abuse of notation these equivalence classes
will b e denoted by their representatives
A constrained pre typ e with n is a simple constrained pre t yp e since glb A A Therefore
simple constrained pre typ es form a subset of constrained pre typ es Ground typ es can also b e
viewed as a subset of constrained typ es Namely if t is a ground typ e a constrained typ e glb t
can b e formed Let t and t b e ground typ es Then
glb t glb t t t t t
G
by the de nition of subtyping and entailment
Note that all constrained typ es with unsatis able sets of constraints are equivalent and playa
role of the top typ e denoted in the constrained typ e hierarchy Indeed let X C A and
X glb C A where C is unsatis able Then
i
i i
X X i C C A A TRUE
G
i i
for all C A and A by the de nition of entailment
i i
The equivalence class therefore has invalid or empty typ es as its representatives The
statement that a particular constrained typ e X glb C A do es not b elong to this class will b e
i i
i
written as
X
G
with the interpretation
def
X X i C
G G i
the last equivalence follows from the de nitions of equality subtyping and the class
On the other hand a constrained typ e of the form plays a role of the b ottom typ e denoted
since for any constrained typ e X glb C A
i i
i
X i C A TRUE
i G i
since FTV C FTV A and thus it is p ossible to cho ose A to satisfy the entailment
i i i
In order to emphasize that a subtyping relationship b etween two constrained typ es X and X
dep ends on a given typ e graph G the entailment will often b e written as X X instead of
G
just X X
So far all the basic notions of the typ e system theory have b een de ned and the validity of the
core entailment algorithms with resp ect to the given interpretation of subtyping constraints has b een
demonstrated In the following section these results and notions will b e used to prove the sub ject
reduction theorem that establishes correctness of the typ echecking
Sub ject reduction
The sub ject reduction theorem is the most imp ortant result of this chapter as it proves that a
successfully typ echecked program do es not generate typ e errors at run time
One of the preliminary results that is needed to prove sub ject reduction is the static subsumption
theorem It states that a more precise typ e sp eci cation leads to a more precise typing of the result
of the computation This result is proven in Section
In order to prove the correctness of a typ echecking algorithm for any language its semantics has
to b e formally de ned This is done in Section
The de nition of typ e errors and the way reduction interacts with typing is determined by the
typ es of the run time ob jects that are pro cessed during program execution Questions related to
run time ob ject typing its de nition and semantics are considered in Section
Issues related to semantics and correctness of the b ehavior dispatch pro cess are formally devel
op ed in Section A theorem stating that a correctly typ echecked b ehavior application always
dispatches correctly no message not understo o d or message ambiguous errors is also proven
in this section
Finally Section presents the pro of of the sub ject reduction theorem
Static subsumption
In this section the static subsumption theorem will b e proven The intuitive meaning of this theorem
is as follows
Assume that an expression is givenatyp e bythetyping rules in Figure under certain assumptions
ab out the typ es of variables participating in the expression Assume further that a new set of
is formed in suchaway that for every variable it gives the same or lesser typ e then assumptions
the old assumption set did Then the theorem states the same expression will also b e typable in the
new environment In addition to that the typ e inferred for the expression in the new environment
will b e a subtyp e of the typ e inferred for the expression in the old environment
Before the pro of of the static subsumption theorem can b e given two additional lemmas haveto
b e proven The rst one simply states that di erent branches of typ e inference algorithm intro duce
indep endentsetsoftyp e variables The next one shows howsubtyping relationship b etween individ
ual simple constrained typ es that take part in two di erent constrained typ es leads to a subtyping
relationship b etween the constrained typ es themselves
Lemma Indep endentfreevariables Sets of free typ e variables intro duced by di erent
branches of typ e inference pro cess haveanemptyintersection
Proof Immediate from the rules in Figure
Lemma Entailment conjunction If
j
j
j j
A glb C i C f g glb C A
i
i j J i i
i i
j J
i
i
C f g X
N N
i N
i N
i
X
N N
N
N
FTV X f g
N
N
FTV C f g
N N
N
N
N
i i F f g F f g
i i
i i
f g F i i i F
i i i
F f g F i i i
i i i
where
def
j j
F A n FTV C FTV C
i
i i
j J
i
j j
def
F FTV C A n FTV C
i
i i
j J
i
then
j j j
i N
A A X C glb C
N
N j j J J
N
i N
N
N
i
j j j
i N
glb X C A A
N N
i N N
j j J J
N N
i
Proof Let X C A Then the conclusion of the lemma is equivalentto
X X
N
A A C C
N N X
N N
j J J j
J J
N N
N
N
j j j
i
N i
C C A A C
X N
i N N
i
N
i i
j j
N
N
A A A A A A
N N X X N
N N N N
N
In order to prove this it is su cienttoshowthat
j j J J
N
N
i
N
C C A A C
N X N
N N i
i
J J
N
N
j j j
N i
A C C A
N X
N N
i
N
i
j j
N
N
A A A A A A
X N N N X
N N N N
N
On the other hand condition is equivalentto
j j
C A i g C A C f
i
i i i
i i
j J
J
i
i
from which
j j
i i
A C C f i j g C A J
i
i i i i
i i
i
J
i
Thus
j j
i i
g C A C f j j J A J i C
i
N i i i
i i
N
J
i
In order to prove it is su cienttoshow that for each J J and
N
N
anytyp e variable assignment S that satis es
N i
C C A A C
X N N
N N i
i
there exists an extension S that satis es
e
j j j
N i
C A A C
X N
N
N
N i
i
j j
N
N
A A A A A A
X N N X N
N N N N
N
J J b e arbitrary indices and S an arbitrary typ e assignmentthat Let
N
N
satis es If no such S exists the statement is trivially true De ne
if S
i
i
S
i
S otherwise
S is an extension of S since
i
A
FTV C FTV A C FTV
i i i
J
i
satis es from conditions and of the lemma Furthermore S
i
i
C C
i
i i
for all i from and From this and there exists an extension S of S that
i i
satis es
j j
i i
A A C
i
i i
Let
n
S
S if dom S
i i
This de nition is valid since
dom S dom S i i i dom S
i i
from conditions and of the lemma and
S S dom S i i S
i i
since S are extensions of S S thus de ned is an extension of S and S for each i It also
i i
satis es by de nition of S and S
i
j
i
i
Let A A and Then condition implies that
i i
i i
i
i
j
i N
i
g C A A A C fA
X N N
i N N
i
i
j j
N
A C A
N X N
N
N
j j
N
N
A A A A A A
N X X N N N
N N N
N
The variable assignment S satis es
j
i N
i
C fA A g C A A
X N N
i N N
i
i
by and and therefore there exists an extension S of S suchthatS satis es
e e
j j
N
A C A
N X N
N
N
j j
N
N
A A A A A A
X N N N N X
N N N
N
it follows from However
i S S
i e e
i
by de nition of S and from the fact that S is an extension of S for all i Therefore since S
e e
i i
satis es it also satis es
j j
N
A C A
N X
N
N
N
j j
N
N
A A A A A A
N X X N N
N N N N
N
From this and S satis es
e
J J and anytyp e variable Thus it has b een shown that for any
N
N
assignment S that satis es there exists an extension S that satis es if the conditions
e
of the lemma are satis ed This proves the statement of the lemma
The following de nes subtyping relationship b etween typing environments as a straightforward
extension of subtyping relationship b etween typ es
De nition Typing environment ordering If and are typing environments then
def
hnamei Id C hnamei hnamei C
Theorem Static subsumption If
hexpri X
C
then
hexpri X
X C X
Proof Theproofisdoneby transforming the derivation of into the derivation of This
is done by induction on the depth of the derivation tree Since the expression is the same in b oth
cases it is p ossible to apply the same rules in the same order to obtain the necessary derivation
Base The derivation of has depth Thus the derivation includes only one application of
the rule Axiom the expression hexpri consists of a single variable u and u X Then
u X and C X X since C Thus it is p ossible to build the derivation
of as a single application of the rule Axiom where the derived typ e is X Since C
X X the base case is proven
Induction step Assume that for all derivations of of depth less or equal to n n
the statement of the theorem is proven It will b e shown that in this case the statementof
the theorem is also true for all derivations of depth n The pro of is by cases dep ending on the
rst ro ot rule applied in the derivation of
The general schema is as follows rst it is shown that the typing environments in the premises
of eachrulehave the same relationships as the ones in the rule conclusion Then the induc
tion assumption is used to establish the subtyping relationship b etween typ es inferred for the
premises of the rule Finally Lemma is used to derive the subtyping relationship b etween
the typ es derived in the conclusion of the rule In all cases conditions
and of Lemma follow from Lemma and the fact that new variables intro duced
in the derivation are always fresh Condition is always a consequence of the induction
hyp othesis Condition is satis ed by the appropriate choice of X The only condition
that has to b e proven individually for each case is the condition The set of indices i
for each rule is the set of numb ers from to N where N is the numb er of premises in the rule
under consideration
Rule Axiom Can t happ en since if the ro ot rule is Axiom then n
Rule Abs The detailed pro of will b e given for this case only since all other cases are similar
and di er primarily in de nition of X used in Lemma
Since this rule is the ro ot one the expression under consideration is fun x hexpri
First it will b e shown that if C then
g fx g fx g C f
y where are fresh Since y and y y for all y x it is su cient
x to showthatC f g x i e C f g whichis
g FTV C Thus equation has b een proven always true as f
Since the rule Abs has b een successfully used its conditions are satis ed and therefore
hexpri X
where the derivation of equation has depth n By induction assumption and
from equation
hexpri X
and
C f g X X
Therefore
fun x hexpri X
where
i i
X glb C A
i
i
i
X A glb C
i
From the original derivation it is also known that
fun x hexpri X
i i
X glb C A
i
i
i
X glb C A
i
The only thing left to prove is therefore
X C X
This can b e obtained by using Lemma with N and
def
X
In order to use Lemma it has to b e shown that condition is satis ed i e
C X X
This follows from the fact that
whichisimmediately true
Rule Appl Here N andX is chosen to b e
def
X
Condition necessary for the applicability of Lemma follows from
whichisimmediately true as
Rule Pro duct Here N n and X is chosen to b e
def
X
n n n
Condition necessary for the applicability of Lemma follows from
i n
i n
i
i i
i i
i i
whichisimmediately true
Rule Seq Here N andX is chosen to b e
def
X
Condition necessary for the applicability of Lemma follows from
whichisimmediately true
Rule Let Before Lemma can b e used here it has to b e shown that
fx X fx X g g
where
hexpri X
hexpri X
then However if
fx X g fx X g
follows from equations induction hyp othesis and the de nition of Thus
is proven and it is now p ossible to use Lemma Let
def
X
Then condition necessary for the applicability of Lemma follows from
whichisimmediately true
Rule Typ edLet Before Lemma can b e used here it has to b e shown that
fx T g fx T g
def
expand T However if where T then
G
fx T g fx T g
follows from the de nition of Thus is provenanditisnowpossibletouse
Lemma Let
def
X T
Then condition necessary for the applicability of Lemma follows from
T T
T T
whichisimmediately true as
T
Thus for all cases it has b een shown that the induction assumption for all n N where N
implies the statement of the theorem for N The induction base for N has also b een pro ven
and therefore the statement of the theorem is true for all N
Natural semantics
This section de nes the natural semantics of the target language that will b e used to show the
soundness of the presented typ e checking algorithm
The run time ob jects rt objects of the language comprise the set O Rt ob jects will b e denoted
Type as a b c Each rt ob ject of the language has a typ e This will b e written as object T
Rt ob jects of the language are
Atomic constants These are constants explicitly de ned by the program and the initial environ
ment suchas unit etc Behaviors declared in the program are considered to b e atomic
constants as well The set B O is the set of all b ehaviors declared by the program
Pro ducts A pro duct ob ject is an ordered list of run time ob jects
a a
n
where a P O Pro ducts of rt ob jects comprise the set P O As usual it is assumed that
i
a a
and therefore O P O
Closures Closures are function abstractions together with the environment they are de ned in
They are denoted as closure E x expr Here E is the environment x is the formal argument
and expr is the b o dy of the abstraction
Run time ob jects are irreducible and can app ear as the nal result of a successful program execution
reduction
The run time environment rt environment E is a set of name to rt ob ject bindings of the form
hnamei a where name Id set of identi ers and a O Given an rt environment E E hnamei
denotes the rt ob ject a in the binding of the form hnamei a in E or if hnamei is unb ound in E
The op eration E E constructs the new rt environment that includes all bindings in E and
those bindings of E that are not overridden in E Formally
E hnamei if E hnamei
E E hnamei
E hnamei if E hnamei
The store S is an unsp eci ed entity that represents the storage space of the program For the
purp oses of this section it is su cient to state that there exists a predicate Valid S de ned on
all p ossible stores an initial store S suchthatValid S TRUE and a set of primitive functions
fprimitive g Thevalidityofa storemayormay not dep end on the typing environment
i
Primitive functions are intro duced to mo del low level system primitives Each primitive function
is a partial function that maps pairs S a to S a This mapping has the following meaning if
primitive S a S a then the primitive function primitive applied to an rt ob ject a in the
i i
presence of the store S pro duces the result a and changes the store to b ecome S
Primitive functions are the most basic execution primitives and corresp ond to low level implemen
tation functions Their correctness is not checked rather it is assumed The right set of primitive
functions along with their de nitions and the pro of of their correctness is the resp onsibility of the
language designer
Before the natural semantics can b e de ned certain assumptions ab out the underlying user typ e
graph G need to b e established It is assumed that G has the following prop erties
Pro ducts It is assumed that the following de nitions are given
concrete type T ProductN covar X covar XN
for all N from to M where M is the maximum arity of pro duct expressions in the program
M is nite since every program is a nite text at the same time pro ducts can not grow
dynamically in the prop osed semantics Existence of the typ e de nition
concrete type T Unit
Unit can b e thought of as a ary pro duct typ e It is further is also assumed The typ e T
assumed that none of the ab ove pro duct typ es has anysubtyp es or concrete sup ertyp es The
existence of a prede ned rt ob ject unit of typ e T Unit is also assumed
Functionals It is assumed that b ehavior and function typ es are de ned as
concrete type T Function contravar A covar R
concrete type T Behavior contravar A covar R
subtype of T Function A R
It is assumed that there are no concrete subtyp es of T Behavior and that the only concrete
subtyp e of T Function is T Behavior Instead of T Function A R andT Behavior A R the
denotations A R and A R resp ectively will b e used
b
The assumptions ab out the pro duct typ es play a crucial role in de nitions of b ehavior consistency
and the treatmentandtyping of pro duct expressions Assumptions ab out functional typ es are
used in typing and treatment of abstraction and application expressions The assumptions ab out
non existence of concrete subtyp es of the functional typ es can b e lifted provided the appropriate
reduction rule for application expression is added
The natural semantics of the target language is de ned in Figure The statement of the form
S E hexpri S a
G
means that the expression hexpri evaluated in the environment E with the store S reduces to
rt ob ject a and changes the store to b ecome S
The function dispatch b a B O O is de ned by De nition
In this section natural semantics of the target language has b een de ned The next section
discusses issues related to run time ob ject typing
Execution state typing
In this section typing of run time ob jects and correctness of a particular state of program execution
will b e de ned The correctness condition placed up on primitive functions and their asso ciations
will also b e formulated
De nition Extended typing environment An extended typing environment isaset
of pairs a X where X is a typ e and a Id O
An extended typing environment is a straightforward extension of typing environment designed
to handle typing of run time ob jects In this section the term typing environment will b e used
to mean extended typing environment The notion of initial extended typing environment is
de ned as a straightforward extension of initial typing environment De nition
De nition Run time ob ject typing If is a typing environment De nition and
a is an rt ob ject then its typing is de ned by the rules depicted in Figure which augment the
rules in Figure Here E denotes the environment obtained as follows
X if E hnamei and E hnamei X
E hnamei
otherwise
De nition RT similarity Twotyp es A and A are called rt similar i one of the fol
lowing is true
E hnamei
RedAxiom
S E hnamei S E hnamei
G
RedFunction
S E fun x hexpri S closure E x hexpri
G
S E hexpri S a S E hexpri S a
G n G n n
n
RedPro duct
S E hexpri hexpri S a a
G n n
n
S E hexpri S a S E fhnamei a g hexpri S a
G G
RedLet
S E let T hnamei hexpri in hexpri S a
G
S E hexprsi S a S E hexpri S a
G G
RedSequence
S E hexprsi hexpri S a
G
S E hexpri S closure E x hexpri S E hexpri S a
G G
S E E fx a g hexpri S a
G
RedFuncApplication
S E hexpri hexpri S a
G
S E hexpri S behavior behavior B
G
S E hexpri S a
G
dispatch behavior a fun x hexpri
S E fun x hexpri a S a
G
RedBehApplication
S E hexpri hexpri S a
G
S E hexpri S behavior behavior B
G
S E hexpri S a
G
dispatch behavior a primitive
i
primitive S a S a
i
RedBehPrimApplication
S E hexpri hexpri S a
G
Figure Natural semantics of the target language
a X
RTAxiom
a X
j j
j j
n n
a glb C A A a glb C
n
j n n j
n
RTPro duct
j j
i
j
n
a a glb C A A
n i
j j
n
i
n
E fun x hexpri X
RTClosure
closure E x hexpri X
Figure Typing rules for rt ob jects
A A
Arity a Arity a
i i
and for each iA is rt similar to A A a A A A a A A
Arity a Arity a
A a A A A a A A and a f g
b
Rt similarity requires that twotyp es b e identical when their leaves related to functional typ es
are cut o For example a b c d e is rt similar to a f g d e but a b c d e isnot
rt similar to a f g d e
De nition Run time pre typ es Run time pre type p over G is de ned recursively as fol
lows
If p A where A is a typ e over G FTV such that pfunctor A Concrete and
G
pfunctor A f g FTV A
b
then p is a run time pre typ e
If p p p where p are run time pre typ es suchthat
n i
i j i FTV p FTV p
i j
then p is a run time pre typ e
Thus a run time pre typ e can contain variables in the leaves of functional typ es only Thus
a b c is a run time pre typ e while a b c is not
De nition Run time typ es Run time type q over G is de ned as follows
i
q glb C p
i
i
is a run time typ e i the following holds
i p is a run time pre typ e
i
i
i C
G
i j p and p are RT similar
i j
The set of all run time typ es is denoted RTyp
G
Run time typ es are thus greatest lower b ounds of a nite numb er of rt similar consistent run time
pre typ es For example
glb a a b
is a run time typ e while
glb a a
is not
De nition Primary form of run time typ es extended from page ab ove
primary is extended to work for run time typ es in the following manner
G
def
i
for some ig primary q fhc c ijc pfunctor q
G n j
j
where
i i i
q glb C q q
i n
i
This de nition is valid since pfunctor q is indep endentofi according to For example
j
the primary form of the typ e is h i
Having de ned the run time ob ject typing it is now p ossible to formally sp ecify the requirements
placed on primitive functions The primitive functions are assumed to b e correct in the following
sense
De nition Primitive function correctness A primitive function primitive is correct
i
w r t i for every b ehavior asso ciation of the form
behavior C A R hnamei primitive
i
a a
for any store S such that Valid S TRUE for each rt ob ject a suchthat a X X
a
glb C A and
i
i
i
a
C A A i C
i G
i
the following holds
primitive S a S r
i
Valid S TRUE
r r
R r X glb C
j
j j
a r
i j C C A A C R R
i G j
i j
In other words the primitive functions are required to b ehavejustasgoodastyp e checked non
primitive ones w r t their typ e sp eci cations Note that there is no de nition of store consistency
here as it dep ends up on the semantics of primitive functions However the results of this chapter
do not dep end on the de nition of store consistency It is only required that correct applications
of primitive functions do not disturb it as stated in the ab ove de nition An example of a set of
primitive functions satisfying these conditions is given in Section
In this section execution state run time ob ject typing was de ned Next section provesaset
of correctness prop erties for b ehavior dispatch pro cess
Dispatch correctness
In this section several prop erties of dispatch function used in Figure are proven The ultimate
goal is to prove that in a correctly typ echecked expression the dispatch is always valid and correct
no message not understo o d or message ambiguous errors
Lemma Argument prop erty If q RTyp then
G
q q
i C C A A primary q primary C A
G G G G
i i
q q q
qp qp
i C C A A C A A A
G
i i i
q q q
t t
i t concrete C A C C A A C A A A
G G
i i i
q q
t t qp qp
where q glb C A abstract primary t C A and abstract primary q C A
G G G G
i
i i
Proof The statement can b e equivalently formulated as follows
q q
A primary q primary C A A i C C
G G G G
i i
Then all three statements of this lemma have to b e proven for all i Let i b e suchthat
q q
C C A A
G
i i
For such i all three statements are trivially satis ed false premises imply any conclusion In the
rest of the pro of it will b e assumed that i is suchthat
q q
A A C C
G
i i
is satis ed The ab ove condition is equivalent to the following statement
q q
C C A A
i i
def
q q q
Then A A Let A A Assume without loss of generality that A A
n
i i i
A A and
n
q
A A for all j from to n
j
j
i
q
from the de nition of subtyping and the variance of the pro duct Since A is an n arity pro duct its
i
q q
q
primary form is also an n arity pro duct Let primary q ht t i Note that t Concrete
G G
n
j
from the ab ove de nition the de nition of a run time typ e and the fact that q RTyp Then
G
t t t
A A A by de nition of abstract
G
n
q
Each A by de nition of a run time typ e has a primary functor which b elongs to Concrete
j G
i
q q
Thus A c r r where c is a concrete typ e constructor Then t and therefore c
j
Arity c
i j
q
t
A c At the same time A c for some c and since A A and from the de nition
j
j j j
i
c Since A c either A c orA for some k IfA of subtyping c
G j j k j k
j
then since C is true by de nition of the following is true
glb fc j c C g pfunctor A
G k
j G
q
and therefore since A A
j
j
i
q
glb fc j c C g t
G k
G
j
q
On the other hand if A c c then t c To sum up the following statementhavebeen
G
j
j
shown to b e true
glb fc j c C g if A is a variable
k j
q
G
t
G
j
c if A c
j
and the ab ove case analysis is exhaustive w r t the form of A The ab ove is equivalentto
j
q
t primary C A
G G j
j
and due to the fact that j was arbitrary to
q
q
i hprimary C A primary C A i primary C A t primary q ht
G G G n G G
n
which proves
In order to show that is true it is su cienttoput
i
r
k jk
j
where
q
i i
r c A r
j
Arity c
j j
i
Then the following is satis ed by de nitions of primary abstract and a run time typ e
G G
q p
q
A A
j
i j
q
qp
C C
i
from which
q q
qp qp
A A C C
i i
Since and were chosen under the only assumption that
q q
C C A A
i i
was satis ed the following is true
q q q
qp qp
C C A A A A C
i i i
This implies
Consider primary q Since primary q primary C A and according to the de nition
G G G G
of concrete there are only two p ossibilities
G
primary q concrete C A In this case the statement is immediate
G G
qp t qp t t t
t concrete C A primary q t C C C A A A where C A
G G G G
abstract t In this case by
G
q q q
qp qp t qp t
t concrete C A C C A A C A A A C A A A
G G
i i i
which implies
q q q
t t
A A A C A A t concrete C A C C
G G
i i i
that is equivalent to
The following theorem shows that indeed a dispatchofatyp e correct b ehavior application yields
a correctly dispatched function
Theorem Dispatch correctness If q RTyp is a run time typ e b is a b ehavior that
G
satis es coverage unambiguity and correctness conditions
d d d
behavior C A R i N
d
i i i
are the b ehavior de nitions for b
a a a
association C A R i N
a
i i i
are the b ehavior asso ciations for b
x
x fa dg i N C
x G
i
and
q q
x x
C A A x fa dg i N j C
x G
i i
j j
then the following holds
k dispatch b q
G
q q q
x x a a x
x fa dg i N j C C A A C A A A
x G
i i k k i
j j j
q q
a a
j C C A A
G
k k
j j
q q
where q glb C A and t primary q
G
j
j j
Proof
Point According to de nition in order to show k it is necessary to sho w that
b
S t
b
jS t j
min
Point There are two p ossible cases
q q
a a
i j C C A A In this case the statement of Lemma can
G
i i
j j
b e applied to deduce that
a a
t primary C A
G G
i i
b
which ensures that S t
q q
d d
The statement of Lemma can b e applied A A C i j C
G
i i
j j
to deduce that
q q q
t d t d d d d
A A C A A A C C A t concrete C
G G
i i i i i
j j j
t t
where C A abstract t From the b ehavior coverage condition
G
t d t d a t a d
C C A A C A A A
G
i i l l i
From this and
q q q
t a d t a d d
A A C A A A C A A C
G
l i l i i
j j j
Thus
q q q q
d d a d a
l C C A A C A A A C
G
i i l i l
j j j j
and since
q q
d d
A A C C
G
i i
j j
by the condition of this case the following is true
q q
a a
C l C A A
G
l l
j j
The statement of Lemma is then used to deduce
a a
l t primary C A
G G
l l
whichproves the statement under consideration
b b
Point In order to show jS t j it is su cien ttoshowthat S t whichhas
min
already b een proven and
a a a a
A t primary C A i j i t primary C
G G G G
j j i i
a a
k t primary C A
G G
k k
a a a a
A primary C A primary C
G G G
i i k k
a a a a
primary C A primary C A
G G G
k k j j
where t primary q From the de nition of run time typ e
G
n
q RTyp t primary q t Concrete for some n
G G G
Let t b e such that the premises of are satis ed Then
n
a a a a
t primary C A t primary C A t Concrete
G G G G G
i i j j
From this and the de nition of concrete
G
a a a a
u concrete C A C A t u
G G
i i j j
From this and the b ehavior unambiguity condition
a a a a a a a a
primary C A primary C A primary C A primary C A
G G G G G G
i i j j j j i i
a a
k u primary C A
G G
i i
a a a a
primary C A primary C A
G G G
k k i i
a a a a
primary C A primary C A
G G G
k k i i
There are three p ossible cases
a a a a
primary C A primary C A Let k i Then k satis es
G G G
i i j j
a a a a
primary C A primary C A Let k j Then k satis es
G G G
j j i i
a a a a a a
k u primary C A primary C A primary C A
G G G G G
i i i i
k k
a a a a
primary C A primary C A In this case let k k Then k
G G G
i i
k k
satis es
b
t j has b een sho wn In all cases k that satis es has b een found Thus jS
min
b
t j Th us the p oint It has b een shown that under the conditions of the theorem jS
min
has b een proven
Point Assume that x i j are such that
q
x x
C C q A
G
i i
j
Then the statement is trivially satis ed In the rest of the pro of it will therefore b e
assumed that x i j are suchthat
q
x x
C q A C
G
i i
j
is satis ed There are two p ossible cases
x a In this case
q q
a a
C C A A
G
i i
j j
Then k from statemen t If k i the statement is immediate Let
k i Then
a a a a
A primary C A t primary C
G G G G
i i k k
b
from the de nition of dispatch and S t From the statement of Lemma
min
q q q
a a qp qp a
C C A A C A A A
G
i i i
j j j
qp qp u a a
where abstract primary q C A Let X abstract primary C A
G G G G
k k k
Then
u a a
primary X A t primary C
G G G G
k k k
a a
A t primary C
G G
i i
from and the de nition of primary andabstract and therefore there are
G G
by de nition of concrete two p ossible cases
G
qp qp a a u
a primary C A concrete C A X From this and
G G
i i
k
q q q
a a u a a t t a
t concrete C A X C C A A C A A A
G G
i i k i i i
j j j
qp qp
cho ose t primary C A
G
a a u qp a t qp t a
b t concrete C A X t t C C C A A A
G G G
i i i i
k
qp qp t t
where t primary C A and C A abstract t From and the
G G
entailmentabove
q q q
a a t qp t a
C C A A C A A A A
G
i i i
j j j
which is equivalent to cho ose t t
Thus it has b een shown that in b oth cases is satis ed From the b ehavior correct
ness condition and
t a t a a t a a
C C A A C A A A
G
i i k k i
From this and
q q q
a t a a a a
A A A A C A A C C
G
i k k i i
j j j
whichproves statement of the theorem for this case
x d From the pro of of the second case of statement
q q q q
a d a d d
A A C A A C A l C C
G
l i l i i
j j j j
From the previous case let x d i l
q q q
a a a a a
C C A A C A A A
G
l l k k l
j j j
From this and
q q q
d d a a a d
l C C A A C A A A A
G
i i k k l i
j j j
whichimplies
q q q
d d a a d
C C A A C A A A
G
i i k k i
j j j
that proves in this case
Point Immediate consequence of statement and the theorem conditions
In this section it has b een proven that in a correctly typ echecked expression the dispatchisalways
valid and correct no message not understo o d or message ambiguous errors Next section is
the pro of of the sub ject reduction theorem
Sub ject reduction
The sub ject reduction theorem that is proven b elow is the main result of this chapter It shows that
a correctly typ echecked program do es not pro duce typ e or dispatch errors during execution
Lemma Expanded typ e propagation If all typ es in are expanded De nition E
is an rt environment o Expressions O and E o X then X is expanded
Proof By simple induction on the derivation of E o X Follows from the fact that none
of the rules in Figure and Figure can pro duce non expanded typ es provided their premises
do not contain them
A consistent triple de ned b elow can also b e termed as a consistent computation state
De nition Consistent triple A triple S E hexpri is called consistent in a given typing
environment if the following conditions are satis ed
Valid S TRUE
E hnamei a hnamei X a X X X
n a G a n
o Id O E o X X
G
E hexpri X X
G
This de nition requires that all typ es of rt ob jects that participate in a given environmentare
valid and so is the typ e derived for the expression expr It also requires the validity of the store S
Finally the sub ject reduction theorem can b e formulated and proven
Theorem Sub ject reduction If do es not contain non expanded typ es and a triple
S E hexpri isconsistent in then the following holds
The next reduction step for S E hexpri exists and is unique The reduction step is under
sto o d as a step from the conclusion of the rule to its premise or from one of the premises of
the rule to the next one in the order these premises are listed
If in addition S E hexpri S a then the following holds
G
a Valid S TRUE
b a X
c X X where E hexpri X
G
Proof
Point The pro of is by induction over the derivation of S E hexpri S a It will b e
G
shown that if the theorem is satis ed for the premises of a reduction rule and the triple in the
conclusion of the rule is consistent then the pair that this triple reduces to according to the
conclusion of the rule in question will also satisfy the theorem
Rule RedAxiom Since S E hnamei is consistent Valid S TRUE Let E hnamei a
E hnamei exists since otherwise the rule in question would not b e applicable Then
hnamei X
n
a X
a
X X
G a n
from the de nition of triple consistency It is left to showthat E hnamei X
and X X Since hnamei X and hnamei Id E hnamei X by
G n n a
de nition of E and the op eration Thus X X From this and equation
a
X X
G n
Thus the pair S a satis es the conclusions of the theorem
Rule RedFunction Immediate from the rule RTClosure in Figure
Rule RedPro duct First it will b e shown that if S E hexpri hexpri is consistent
m
and Valid S TRUE then S E hexpri is consistent It is su cient to showthat
i
under these conditions
n
E hexpri X
i
i
n
X
G
i
From the de nition of consistency
n
E hexpri hexpri X
m
X
G
Consider the derivation of Itfollows the rules of Figure and the last applied
rule has to b e the rule Pro duct Thus
n
E hexpri X
i
i
where
n n
n n j n j
i i
X glb n C A
i j i i
i
n n n
n j n j n j n
i m
C A A X glb n
n
i
i m j j
m
Thus equation is proven Since
n n n
n j n j n j n
i m
C A A X glb n
n
i G G
j j
i m
m
n n n
n j n j n j
i m
C A A
G i
i m
n
n
j j
m
n
n j
i
C
G i
i
n
n
j j
m
n
n j
i
C
G
i
n
n
i j j
m
n
n j
i
C
G
i
n
i j
i
n n
n j n j
i i
C A
G
i i
n
i j
i
n n
n j n j
i i
A glb n C
G
i j i
i
i
n
X
G
i
i
the equation is proven as well equivalences and are due to the fact that
all typ es are expanded which follows from Lemma and the conditions of the theorem
Therefore S E hexpri is consistent as long as Valid S TRUE Since S
i
TRUE by assumption S E hexpri is consistent Therefore by induction assumption
Valid S TRUE Thismakes S E hexpri consistent and S valid After n
steps it is shown that all triples S E hexpri are consistent Then by induction
i
i
assumption
a
a X
i
i
n a
X X
G
i i
It is left to show that
a
a a X
n
a n
X X
G
From equation and the rule RTPro duct Figure
a
a a X
n
where
a a
a a j a j
i i
X glb a C A
j
i i i
i
a a a
a a j a j a j
i m
X glb a C A A
a
i
j j i m
m
Thus equation is proven Equation is equivalentto
n n n a a a
n j n j n j a j a j a j
m i m i
A A glb n C A A glb a C
n a
i G i
m j j i m j j i
m m
a a a n n n
a j a j a j n j n j n j
i m i m
C A A C A A
G i i
i m i m
n a
n a
j j j j
m m
n a a a n n
n j a j a j a j n j n j
i i m m
C C f A A A A g
i G i
i i m m
a n
a n
j j j j
m m
n a a n
n j a j a j n j
i i i i
C C fA A g
i G i i
i i i i
a n
a n
j j j j
m m
n a a n
n j a j a j n j
i i i i
C C fA A g
G
i i i i
a n
a n
j j j j i
m m
n a a n
n j a j a j n j
i i i i
C C fA A g
G
i i i i
a n
i j j
i i
n n a a
n j n j a j a j
i i i i
A C A C
G
i i i i
a n
i j j
i i
n n a a
n j n j a j a j
i i i i
A glb n C A glb a C
G
j j
i i i i
i i
i
a n
X X
G
i i
i
However the equation is the same as and therefore the equation is
proven The ab ove derivation used equations and The step is a
n a
direct consequence of Lemma and the fact that the derivation of X X o ccurs in
i i
n a
a branch di erent from the one used to derive X X ifi j
j j
Thus it has b een shown that S a a satis es the conclusion of the theorem
n n
Rule RedLet First it will b e shown that if
S E let T hnamei hexpri in hexpri
is consistent then so is
S E hexpri
Store validity is immediate thus it remains to show that
n
E hexpri X
n
X
G
under the conditions that
n
E let T hnamei hexpri in hexpri X
n
X
G
The outermost rule in the derivation of is either Let or Typ edLet Therefore
n i n i n
E hexpri X glb C A
i
j j
n n n
E fhnamei Y g hexpri X glb C A
j
where
i n i n
glb C A if the rule Let was used
i
Y
expand T if the rule Typ edLet was used
G
whichproves On the other hand
j j
n i n n n
X glb C C c A
i
i j
where
TRUE if the rule Let was used
c
i
i n
A expand T if the rule Typ edLet was used
G
and therefore from
j j
n i n n n
X glb C C c A
G G i
i j
j j
i n n n
C C c A
G i
i j
j
i n n
C C c
G i
i j
i n
C
G
i
i n i n
C A
G
i
i n i n
glb C A
G
i
n
X
G
whichproves Therefore
S E hexpri
is consistent and by the induction assumption
Valid S TRUE
a
a X
a n
X X
G
From this and the conditions of the theorem it will b e shown that
S E fhnamei a g hexpri
is also consistent Indeed S is valid by It remains to show that
n
E fhnamei a g hexpri X
a
n
X
G
a
Consider two p ossibilities
n n
Rule Let was applied In this case Y X and therefore X Y
G
Rule Typ edLet was applied In this case Y expand T and
G
j j
n i n n i n n
X glb C C A expand T A
G G G
i j
i n i n
C A expand T
G G
i
n
X expand T
G G
n
X Y
G
n a n
Thus in b oth cases X Y is satis ed However from X X and
G G
a
therefore X Y This together with proves that
G
E fhnamei a g E fhnamei Y g
From this and the static subsumption theorem the following is true
The statement is true
The following statement is true
n n
X X
G
a
from which is also true
Thus
S E fhnamei a g hexpri
is consistent and therefore by induction assumption
Valid S TRUE
a
a X
a n
X X
G
a
It remains to show that
n a
X X
G
n a n n n
where X is de ned by Since X X by and X X
G G
a a
n n
by it remain to show that X X Indeed
G
j j
n i n n n
X glb C C c A
i
i j
j j
n n n
X glb C A
j
and since
j j j j
i n n n n n
C C c C A A
i G
n n
X whichproves for all i j by De nition X
G
Rule RedSequenc e First it will b e shown that if
S E hexpri hexpri
is consistent then so is
S E hexpri
Store validity is immediate thus it remains to show that
n
E hexpri X
n
X
G
under the conditions that
n
E hexpri hexpri X
n
X
G
The outermost rule in the derivation of is Seq therefore
n i n i n
E hexpri X glb C A
i
j j
n n n
E hexpri X glb C A
j
whichproves On the other hand
j j
n i n n n
X glb C C A
i j
and therefore from
j j
n i n n n
X glb C C A
G G
i j
j j
i n n n
C C A
G
i j
j
i n n
C C
G
i j
i n
C
G
i
i n i n
C A
G
i
i n i n
glb C A
G
i
n
X
G
whichproves Therefore
S E hexpri
is consistent and by the induction assumption
Valid S TRUE
a
a X
n a
X X
G
From this and the conditions of the theorem it will b e shown that
S E hexpri
is also consistent Indeed S is valid by It remains to show that
n
E hexpri X
n
X
G
The statement is equivalent to and is therefore true From
j j
n i n n n
X glb C C A
G G
i j
j j
i n n n
C C A
G
i j
j
i n n
C C
G
i j
i n
C
G
i
i n n
C A
G
i
n
X
G
whichproves Thus
S E hexpri
is consistent and therefore by induction assumption
Valid S TRUE
a
a X
a n
X X
G
It remains to show that
a n
X X
G
n a n
where X is de ned by Since X X by it remain to showthat
G
n n
X Indeed X
G
j j
n i n n n
X glb C C A
i j
j j
n n n
X glb C A
j
and since
j j j j
i n n n n n
C C C A A
G
n n
for all i j by De nition X X whichproves
G
Rule RedFuncApplication First it will b e shown that if
S E hexpri hexpri
is consistent then so is
S E hexpri
Store validity is immediate thus it remains to show that
n
E hexpri X
n
X
G
under the conditions that
n
E hexpri hexpri X
n
X
G
The outermost rule in the derivation of is Appl therefore
n i n i n
E hexpri X glb C A
i
j j
n n n
E hexpri X glb C A
j
whichproves On the other hand
j j
n i n n i n n
X glb C C A A
i j
and therefore from
j j
n i n n i n n
X glb C C A A
G G
i j
j j
i n n i n n
C C A A
G
i j
j j
i n n i n n
C C A A
G
i j
i n
C
G
i
i n i n
C A
G
i
i n i n
glb C A
G
i
n
X
G
whichproves Therefore
S E hexpri is consistent
and by the induction assumption
Valid S TRUE
a
closure E x hexpri X
n a
X X
G
From this and the conditions of the theorem it will b e shown that
S E hexpri
is also consistent Indeed S is valid by It remains to show that
n
E hexpri X
n
X
G
The statement is equivalent to and is therefore true From
j j
n i n n i n n
X glb C C A A
G G
i j
j j
i n n i n n
C C A A
G
i j
j j
i n n i n n
C C A A
G
i j
j
n
C
G
j
j j
n n
C A
G
i
j j
n n
glb C A
G
j
n
X
G
whichproves Thus
S E hexpri
is consistent and therefore by induction assumption
Valid S TRUE
a
a X
a n
X X
G
Nowitispossibletodemonstratethat
S E E fx a g hexpri
is consistent S is valid by It has to b e shown that
n
E E fx a g hexpri X
n
X
G
From
a
closure E x hexpri X
and therefore by the rule RTClosure for rt ob jects Figure
a
E fun x hexpri X
The outermost rule in the ab ove derivation must b e the rule Abs and therefore
i i
E fx g hexpri X glb C A
e
i e e
a i i
X glb C A
i e e
where is a fresh typ e variable From and
j j
n i n n i n n
X glb C C A A
G
i j
and therefore
I n J n I n J n
I J C C A A
G
By de nition of subtyping
a a
X X
G
and therefore since is true
a
X E E fx a g E fx g
G
From this and the static subsumption theorem
n
E E fx a g hexpri X
n a
X X X
e G
which implies is equivalentto
k n
k C
G
Since is equivalentto
k n k n j i a i a j
C A A i j k C A C
G
e e
by de nition of subtyping in order to prove it is su cient to showthat
i a i a j
i j C A C
G
e
From
j j j
i n a a n
i C C A A
G
j
and from and
j
i n j i n
i C C A A
G
e e
j
From the ab ovetwo equations and
j j j j
I n J n I n J n a a n j I n
C C A A C A A C A A
G
e e
j j
whichimplies
I n J n I n J n J a J a J n I I I n
C C A A C A A C A A
G
e e
which is equivalent due to the variance of and transitivityofsubtyping to
I n J n J a I I n J n J a J n I I n
C C C C A A A A A A
G
e e
J n I J a
A A A
e
This implies
J a J a I
C A C
G
e
and therefore
Thus
S E E fx a g hexpri
is consistent and therefore by induction assumption
Valid S TRUE
a
a X
n a
X X
G
It remains to show that
a n
X X
G
n a n
where X is de ned by Since X X by it is su cienttodemon
G
strate that
n n
X X
G
From by de nition of subtyping
i n i a i a i n
i i C C A A
G
whichisby equivalentto
i n i i n i
A A i i C C
G
e e
From the ab ove and the de nition of subtyping the following is true
j j
i n i i n n i n n i
A A i j i C C A A C
G
e e
Using the prop erties of entailment
j j
i n n i n n
i j i C C A A
G
j j
i n i i n i n n
C C A A A A
e e
from which by transitivityofsubtyping
j j j j
n n i i n n i n n i
A C A i j i C C A A C
G
e e
and byvariance of the typ e constructor
j j j j
i n n i n n i n n i
i j i C C A A C C A A
G
e e
On the other hand from and it follows that
n n
X X X
G e
which is equivalentto
j j
n n i k n k n i
i j k C A C C A A
G
e e
from which and
j j
i n n i n n
i j i k C C A A
G
j j
k n k n i n n i i
C A A C A A C
e e e
which implies by transitivity
j j
i n n i n n
i j i k C C A A
G
j j
i n n i k n k n i k n
C C A A C A A A
e e e
which in turn implies
j j
n k n k n n i n i n
C A A A i j k C C
G
which is equivalentto
n n
X X
G
due to Thus and therefore are proven
Rule RedBehApplication The rst two premises of this rule are the same as those in the
rule RedFuncApplication Therefore the equations are proven in the same
way Since hexpri reduces to a b ehavior behavior the following is true
a
E behavior X
where
i a i a a
glb C A X
i
and
i i a i
R A A
b
b b
From this and
a n i n l a l a l n
X X i l C C A A
G
i n l a l l i n
i l C C A R A
G b
b b
From and
j j
i n n i n n
i j C C A A
G
and from this and
j j
i n n i n n l a l l i n
i j l C C A A C A R A
G b
b b
from which duetovariance of and and their subtyping relationship in G
b
j j
i n n l a n l l
i j l C C C A A R
G
b b
From
j j
n n m a m a
C A A j m C
G
and from this and
j j
i n n l a m a m a n l l
i j l m C C C C A A A R
G
b b
whichimplies
l a m a m a l
l m C C A A
G
b
From this and the dispatch correctness theorem
k dispatch behavior a
G
m a l a m a l k a m a k l
l m C C A A C A A A
G
b b b
k a m a m a k
m C C A A
G
b
There are two p ossibilities the dispatchmight pro duce a function or a primitive The
rst case is handled by the rule RedBehApplication while the second is handled by the
rule RedBehPrimApplication Here only the rst alternative is considered the second one
will b e considered later on Assume that the dispatch pro duced a function F Then by
the functional consistency condition
F X
f
k k a k
R C A X
G
b b f
Since for anyvalid by the static subsumption theorem
p p
E F X glb C A
f
p
f f
X X
G f
f
and therefore
k k a k
R X C A
G f
b b
By using the rule Appl it is concluded that
p p
m a m a n
glb C C A A E Fa X
m p
f f
a
where o ccurs in X only in places denoted explicitly ab ove as it is fresh when the
rule Appl is applied
It is now left to show that
S E fun x hexpri a
is consistent and that the result typ e conforms to the third condition of the theorem S
is valid by In order to show triple consistency it is left to demonstrate that
n
E F a X
n
X
G
def
where F fun x hexpri
follows from is equivalentto
p p
m a m a
m p C C A A
G
f f
From
p p
k k k a
A R A p C C
G
b b
f f
and from this and
p p
k k k a m a m a k
R A A C m p C C A A
G
b b b
f f
k
which implies let R Thus the triple
b
S E fun x hexpri a
is consistent and therefore by induction assumption
Valid S TRUE
a
a X
a n
X X
G
In order to complete the pro of of this case it is necessary to showthat
a n
X X
G
a n
Since X X by it is su cienttoshowthat
G
n n
X X
G
which is equivalentto
j j p p
i n n i n n m a m a
i j m p C C A A C C A A
G
f f
By the de nition of subtyping
j j j j
n n i n n i n n i n i n
A A C C A A i j C C
G
From this and
j j
i n n i n n
i j l C C A A
G
j j
i n l i n n i n n l a l
A R C C A A C A
b
b b
from which and
j j
i n n i n n
i j l m C C A A
G
j j j
i n n i n n l a l l i n m a m a n
C C A A C A R A C A A
b
b b
from which and
j j
i n n i n n
i j l m C C A A
G
j j j
i n n i n n l a l l i n m a m a n
C C A A C A R A C A A
b
b b
k a m a k l
C A A A
b b
From this and
j j
i n n i n n
i j l m p C C A A
G
j j j
i n n i n n l a l l i n m a m a n
C C A A C A R A C A A
b
b b
p p
k a m a k l k k
C A A A C A A R
b b b b
f f
From this and the global b ehavior consistency condition
j j
i n n i n n
i j l m p C C A A
G
j j j
i n m a m a n l i n n i n n l a l
A C A A R C C A A C A
b
b b
p p
l k k k l k a m a k
R R R C A A A C A A
b b b b b b
f f
From this transitivity and relationship b etween and
b
j j p p
l i n n i n n m a m a l
R i j l m C C A A C C A A R
G
b b
f f
l
which implies put R
b
Rule RedBehPrimApplication This rule is identical to RedBehPrimApplication up to the p oint
where the dispatched function is applied Therefore the equations
and are proven in the same way
It now remains to show that under these conditions
primitive S a
i
is de ned the resulting store S is consistent and the typ e of the resulting ob ject is less
then the typ e derived initially for the expression
a m a m a
a X glb C A
m
n a
X X
G
S is valid by Since
m a m a a
glb C A a X
m
k a m a m a k
m C C A A
G
b
by and resp ectively and
primitive S a S a
i
Valid S TRUE
j p
a a a
glb C A a X
p
p p
a a k k a m a m a k
C A R m p C C A A
G
b b
by the primitive function correctness condition Nowitislefttoshow that
a n
X X
G
which is equivalentto
j j p p
i n n i n n a a
i j p C C A A C A
G
From the de nition of subtyping
j j j j
i n n i n n i n n i n n
i j C C A A C C A A
G
From this and
j j
i n n i n n
i j l C C A A
G
j j
i n n i n n l a l l i n
C C A A C A R A
b
b b
From this and
j j
i n n i n n
i j l m C C A A
G
j j j
i n m a m a n l i n n i n n l a l
A C A A R C C A A C A
b
b b
From the ab ove the transitivityofsubtyping relationship b etween and and their
b
variance
j j
i n n i n n
i j l m C C A A
G
j j j
i n n l a m a m a n n l l
C C C C A A A A R
b b
from which and
j j
i n n i n n
i j l m C C A A
G
j j j
l i n n l a m a m a n n l
R C C C C A A A A
b b
k a m a k l
C A A A
b b
From this and
j j
i n n i n n
i j l m p C C A A
G
j j j
n l n l n l a m a m a i n
A A R C C A A C C
b b
p p
a a k l k a m a k
C A R A C A A
b b b
From the ab ove and the global b ehavior consistency condition
j j
n n i n i n
A A i j l m p C C
G
j j j
i n n l a m a m a n n l l
C C C C A A A A R
b b
p p
k k a a k l k a m a k
R R C A R A C A A
l b b b b
from which and the transitivityofsubtyping
j j
i n n i n n
i j l m p C C A A
G
j j j
l k a m a k i n n l a m a m a n n l
A C A A C C C C A A A A
b b b
p p
a a
A C
which implies
Point Since the triple S E hexpri is consistent hexpri is syntactically valid The reduction
rules are structural with the following exceptions
Rule RedAxiom additionally requires that E hnamei
An application expression can b e pro cessed by one of the rules RedFuncApplication Red
BehApplication orRedBehPrimApplication These rules have additional non structural
premises
Assume that hexpri hnamei as is required for the rule RedAxiom to b e applicable Assume
E hnamei Then E hnamei which contradicts the assumption ab out triple
consistency since Thus the rule RedAxiom works for all correctly typ e checked names
G
Assume that hexpri hexpri hexpri The rst premise of all three rules is identical It will b e
shown that under these conditions the rst expression if it reduces reduces to either a closure
in which case the rule RulFunApplication is applicable and its second premise is checked or a
b ehavior in this case an additional analysis is needed Indeed by triple consistency
j j
n i n n i n n
X C C A A
G G
i j
i n i n
C A
G
i
where is a fresh typ e variable and equation is satis ed Also from triple consis
tency is true and therefore
S E hexpri S a
G
Valid S TRUE
l a l a a
glb C A a X
l
a n
X X
G
From and transitivity
l a
i l A
G
a a
Since X is a concrete typ e the primary functor of X must b e concrete The only concrete
a
typ es c such that c are and itself Thus the primary functor of X is either
G b
or The only rt ob jects that can haveatyp e with a primary functor of are clo
b
sures At the same time the only rt ob jects that can haveatyp e with a primary functor of
b
are b ehaviors Thus a must b e either a closure in which case the rule RedFuncApplication is
applicable or a b ehavior
If o is a b ehavior its dispatch fourth premise of the rules RedBehApplication and RedBeh
PrimApplication can
Pro duce a function In this case the rule RedBehApplication will work
Pro duce a primitive In this case the rule RedBehPrimApplication will work
Pro duce an error In this case no rule is applicable
Thus it is su cienttoshow that under these conditions the dispatch will never yield
However this statement has already b een proven in
Thus the statement of the theorem has also b een proven
In this section the main result of this chapter the sub ject reduction theorem has b een proven
The next section describ es incorp oration of imp erativetyp es into the typ e system develop ed so far
Imp erativetyp es
In this section it will b e shown that it is p ossible to consistently intro duce state in the frame
work describ ed ab ove Interestingly state do es not require any sp ecial typ e treatment The set
of appropriate primitive functions along with a particular treatment of store and store validityis
su cient
This is in sharp contrast to ML based typ e system where imp erativetyp es typ e constructor
ref are treated sp ecially by the typ e system This sp ecial treatmenthastwo main disadvantages
It restricts the use of imp erativetyp es by applying less p ermissivetyp e discipline to them
It signi cantly complicates the development of a system with several di erent imp erativetyp es
as for such a system the base typ e theory has to b e mo di ed
The family of imp erativetyp es T Var X is intro duced as follows
type T Var novar X
behavior T Var X X get primitive
behavior T Var X X T Unit set primitive
Var with the additional constraint that there are no concrete typ es b elow T
Let
V fo j o O o T Var g
b e the set of all ob jects with imp erativetyp es The store S is then de ned as a partial function from
V into O For each variable an ob ject of typ e T Var the store gives its contents an ob ject
stored in it
The store validity predicate Valid S is de ned in the following manner
def
v v
Var Valid S v V glb C V i C V T
i G i
i i i
S v o
o
o O glb C O
j
j j
o v
Var C O i j C V T
G j i
j i
An intuitive meaning of the ab ove de nition is that a store is valid if for every variable there is a
value stored in it and that value is of the same or smaller typ e as the typ e of the variable
The semantics of primitive functions is then de ned as follows
primitive S v S S v
getting the valueofavariable v and
primitive S v a S S v a unit
setting the value of a variable v to a In the latter case
S o if o v
def
S S v a o
a if o v
In order to show that this de nition is valid and that in the system extended with imp erative
typ es in this manner the sub ject reduction theorem still holds it is su cient to demonstrate that
the ab ove primitives ob ey the primitive function correctness condition
Getting a value It is necessary to showthatifS is a store and v is an rt ob ject such that
Valid S TRUE
v v v
A v X X glb C
i
i i
v
A T i C Var
i G
i
then the following holds
primitive S v S a where a S v
Valid S TRUE
a a
a X glb C R
j
j
j
a v
Var C R i j C A T
G j i
j i
In order to show it is su cient to demonstrate that S v exists From the
v
fact that X is an rt typ e and the condition that there are no concrete typ es b elow T Var it
follows that
v
Var T X T
where T is some typ e expression From this and the validityof S by
S v a
a a
a X glb C R
j
j j
a
j T Var T T Var C R
G j
j
By S v exists and therefore is proven is equivalent to The
validityof S is trivial by getting a value do es not change the store is
equivalent to and is therefore proven
Thus consistency of the rst primitive getting a value has b een demonstrated
Setting a value It is necessary to show that if S is a store and p is an rt ob ject such that
Valid S TRUE
p
p p
P p X X glb C
i
i
i
p
P T i C Var
i G
i
then the following holds
primitive S p S unit
Valid S TRUE
u
unit X
p
u
Var X T Unit i C P T
G i
i
The statements and are immediately true as unit T Unit Thus it
remains to showthevalidity of and
p
Product the following Since X is a run time typ e and there are no concrete typ es b elow T
is true
i P V S
i i i
At the same time from and the de nition of a run time ob ject
p v s
On the other hand from and it follows that
p
Var i C V T
G i
i
and from the rule RTPro duct
v v
V v X glb C
l l l
s s
S s X glb C
m m m
p v s
X glb C C V S
l m l m l m
From this and
P V S for some l m
i
l m
p
v s
C C for some l m C
l m
i
from which and
V V for some l
i
l
S S for some m
i
m
Let us denote the indices that satisfy the ab ove equations as l and m To sum up the
i i
following statements havebeenproven
p v s
p X glb C C V S
l m
i i
i l m
i i
p v s
v v
v X glb C V
l
i l i
i
s s
s X glb C S
m
i i
m
i
From this and the fact that there are no concrete typ es b elow T Var it follows that
i V T Var U
l i
i
From this and the semantics of primitive
primitive S p S unit
where S S S v s
Thus is true It remains to show that S is valid Since S is valid and S can only b e
di erentfromitonv it is su cient to demonstrate that
v s
T V S l m C Var C
G
l m l m
v
Var from and therefore FTV U X is a run time typ e with primary functor T
i
for all i Also from the de nition of a run time typ e U U for some U and all i From this
i
v
T V and satis ability of run time typ e constraints C Var U Thus that weare
l l
attempting to prove is equivalentto
s
m T Var U T Var C S
G
m m
which is equivalentto
s
m U C S
G
m m
Var Thisisinturnequivalentto due to novariance of T
s
m C S U
G
m m
s
by de nition of entailment and the fact that FTV C S andFTV U
m m
At the same time the condition is equivalentto
s
Var U S Var T i C T
m G
i
m
i
which implies byvariance of pro duct and de nition of m
i
s
T m C Var U T Var S
G m
m
which is equivalentto
s
m C U S
G m
m
Var This is equivalentto byvariance of T
s
m C S U
G m
m
s
due to the fact that FTV C S However the last statementisequivalent to
m
m
Thus has b een proven
It has b een demonstrated that imp erativetyp es can b e treated consistentlyintheframework
presented in this dissertation The de nitions of the typ e T Var b ehaviors get and set along
with their related primitives given at the b eginning of this section were proven to comply with the
requirements set forth for typ e system consistency It follows that the sub ject reduction theorem
holds for the typ e system with imp erativetyp es intro duced in this manner
Extensions
In this section I will describ e several extensions to the simple semantics considered ab ove All these
extensions will b e considered from the p oint of view of their impact on the typ e system
Errors nulls and exceptions
While the typ echecking algorithm guarantees the absence of typ e errors at run time other errors
may still arise A practical programming language has to b e able to deal with these errors in a
consistent and sound manner
Example Consider a primitive function that implements an integer division
associate T Integer T Integer T Integer divide primitiveIntDiv
Division of some number by zero is certainly typ e correct
var T Integer i j
i
j
i divide j print
What should b e the result of such a program Apparently there is no integer numb er that could
meaningfully b e printed by the last statement
If primitive functions were not allowed this problem would not arise since in the absence of
primitives every terminating computation is valid as long as the program is typ echecked In real
programming however the ability of a program and ideally the formal semantics and the typ e
system to deal with this kind of errors is crucial There are several p ossible solutions to this problem
These solutions are not mutually exclusive but usually the presence of one of them is su cient
The notion of a null value is a well established notion in the database community Surprisingly
in the programming languages community it did not receive nearly as much theoretical attention
even though it is constantly utilized in practical programming A null value is in a sense a common
placeholder for missing insu cient or incorrect information Thus there can b e many di erentnull
values e g uninitialized incorrect or absent In Example for example the division func
tion would return some null value indicating incorrect result That value will b e printed probably
as a string and the program will pro ceed normally
This approach is in fact adopted by the IEEE standard for oating arithmetic IEE The role
of null values is played bysuchentities as NaN Unfortunately nosuch standard exists for integer
arithmetics
From the p ointofviewofthetyp e system the following question needs to b e answered what are
the typ es of the null values The simplest consistent approachwould b e to create a concrete typ e
T Null at the b ottom of the typ e hierarchyandmake all null ob jects to share that typ e Then every
function and or b ehavior would b e able to pro duce suchavalue without violating the typ e discipline
There are however certain problems related to this approach First the natural semantics has to
b e extended to deal with null values in functional p ositions since T Null is at the b ottom of the
hierarchy it is a subtyp e of all b ehavior and function typ es and therefore null values can legally
app ear where functions and b ehaviors can If the imp erativetyp es are present the semantics of
extracting a value from a null value p osing as a variable ob ject also has to b e sp eci ed Finally
since T Null is also a subtyp e of all pro duct typ es the distinction b etween b ehaviors that take one
argument and the ones taking several arguments is blurred which requires a signi cant additional
run time supp ort For example consider the following co de
behavior T Point T Integer T Integer intCoords
behavior T Integer T Integer T Integer plus
var T Point p
p intCoords plus print
The last statement is supp osed to print the sum of the integer co ordinates of the given p oint
However the variable p may contain a null value in whichcase p intCoords is likely to pro duce
by default a single null value rather than a pair of them From the p ointofviewoftyp echecking
this is correct But now the b ehavior plus is applied in a typ e correct manner to a single ob ject
instead of a pair Thus a run time system has to b e able to deal with situations like these
The idea of null values and null typ es can b e taken further Namely itispossibletointro duce
several null typ es each for its own purp ose For example one can establish a common subtyp e of
all numeric typ es T NumNull and make ob jects suchasNaN instances of this typ e This approach
allows one to sp ecify precisely what kind of null values can b e exp ected in a particular place in the
program However it still requires additional semantics for function b ehavior applications if at least
one null typeisasubtyp e of these functional typ es
Going even further along this path ob jects of null typ es can have some sp ecial b ehaviors de ned
on them These b ehaviors will dep end on the typ e of nulls These b ehaviors can b e used for example
to extract some information stored in the null ob ject at the time of its creation The resulting null
ob jects will then b ehavemuchlike exceptions in most mo dern programming languages
Note that the main problems related to the intro duction of various null typ es and values are
related to the language semantics and implementation Typ e system issues can b e neatly solved by
placing null typ es b elowthetyp es of ob jects the null values are designed to replace Thus the typ e
system can handle not only null values but also exceptions or at least a mechanism quite similar
to them
Lo cal variables and dynamic scoping
The only di erence b etween null values with attributes and the traditional exceptions is the lexical
scoping of the lo cal variables in the exception pro cessing co de This problem manifests itself in many
other and more imp ortant places as well Namely consider the following co de
Example
a fun x
var T Integer i
i x
return fun y return i y
a print
This co de rst calls the anonymous function stored in a with the argument The result is a
function that is called with the argument The result of that application is printed According
to the semantics sp eci ed in this chapter this co de is valid and should print since the closure
always keeps a copy of its environment In practice however lo cal variables are not kept b eyond
the existence of the stack frame of their function invo cation and therefore an attempt to access i
will fail and return a garbage value The situation can b e even worse
Example
a fun x
var T Integer i
i x
var b fun y return i y
i
return b
a print
According to the sp eci ed semantics this co de should print since the last value stored in i is
Even though it is p ossible to implement a language with suchsemantics e g LISP and some
other functional languages it usually comes at considerable execution and memory costs
In order to avoid situations like these it is p ossible to create a semantics in which all lo cal
variable values accessed inside a lo cal function in their scop e will b e evaluated eagerly rather than
lazily At the same time assignmenttosuchvariables within such functions would b e disallowed
Such semantics would corresp ond to the b ehavior of the most to day s imp erative languages
In order to see how this semantic change can b e supp orted by the typ e system consider program
transformations of the program given in Example The following is the standard transformation
T Var T Function a newT VarT Function
a set fun x
T Var T Integer i newT VarT Integer
i set x
return fun y return i get plus y
a get print
that corresp onds to the original semantics The following translation corresp onds to the mo di ed
semantics
T Var T Function a newT VarT Function
a set fun x
T Var T Integer i newT VarT Integer
i set x
return let ival i get in fun y return ival plus y
a get print
Here the value of i is extracted eagerly This allows the implementation to discard the variable i
while the function that refers to its value is still around Note that this translation automatically
ensures that no assignments to i are made inside the b o dy of the inner function as the typ e of ival
is not a variable typ e
Thus it has b een shown that the typ e discipline presented can supp ort b oth functional lazy
evaluation and imp erative eager evaluation styles
Non lo cal returns
Another common feature of imp erative programming languages that has not yet b een addressed is
the presence of non lo cal returns In the presented semantics the return expression has to b e the
last expression in the function b o dy In imp erative programming this restriction is to o severe to b e
practical The semantic approach to non lo cal returns is the usage of continuations Typing in the
presence of continuations is quite straightforward however their presence unnecessarily complicates
the semantics Since the primary purp ose of this dissertation is the developmentofthetyp e system
continuations were not formally treated here
Handling ob ject creation
Ob ject creation deletion can b e handled within the presented framework analogously to the handling
of imp erativetyp es Section An existential predicate has to b e intro duced as an additional
part of the state and the ob ject creation primitive function semantics has to b e sp eci ed to change
the value of that predicate at a particular p oint Once this is done no changes to the typ e system
are required to deal with ob ject creation The typ e system already in place will ensure absence of
typ e errors in a correctly typ echecked program
In this section several p ossible semantical extensions and their in uence on the typ e system have
b een addressed Next section discusses some key theoretical features of the prop osed typ e system
compares it to other works in the area and outlines future research direction with resp ect to further
development of the typ e system theory
Discussion
In this section several additional asp ects of the presented typ e theory will b e discussed Section
describ es the mo dularity of the theory presented so far Section discusses the e ect that a typ e
system transformation mayhaveonvarious stages of the typ e checking It also uses the ab ove
discussion to showhowtyp e system evolution can b e supp orted by the presented typ e system
Section lists engineering trade o s related to the usage of the presented typ e system Finally
Section presents a summary of the ma jor features of the presented typ e system from the
theoretical p oint of view
Extensibility
One of the signi cant di erences b etween the theory develop ed in this chapter and other typ e theories
develop ed so far is its mo dularity The main part of the theory including the entailment algorithms
and the sub ject reduction theorem dep end only on a very limited set of assumptions ab out the user
typ e graph and the primitive function semantics No assumptions at all are made ab out the store
except for its initial validity This prop ertygives the language designer a very exible and robust
system in which almost any store and primitive function semantics can b e plugged in with very little
e ort
As an example a typ e system that includes imp erativetyp es and state preserving ob jects known
to b e a challenge for typ e systems combining parametric and inclusion p olymorphism has b een fully
develop ed in Section The only part of this theory that required some work was the pro of of
consistency of the primitive functions If a primitive function do es not change the store the pro ofs
of validity b ecome even simpler
Typ e system evolution
So far the user typ e graph was considered to b e constructed at the b eginning of the program
analysis pro cess and used later during program typ echecking This assumption mightbevalid in
theoretical settings but it is quite impractical as big programs are usually built from smaller blo cks
libraries that are typ echecked and veri ed b efore the complete program is assembled The question
that can b e asked of a typ e system with resp ect to the ab ove scenario is what are the program
transformations that do not invalidate typ e checking or invalidate only a part of it
In this section various asp ects of program veri cation presented in Section will b e evaluated
from this p oint of view Before it is done an imp ortant class of program transformations called
covariant transformations is intro duced
Covariant transformations include
Adding a new typ e
Adding a new sub sup ertyp e link under the condition that the user typ e graph remains
acyclic
Adding a new b ehavior
Adding a new b ehavior de nition or asso ciation to an existing b ehavior
Replacing an existing b ehavior de nition asso ciation with a de nition asso ciation with a
subtyp e of the original
Adding a new constant de nition
Replacing an existing constant de nition with a de nition with a subtyp e of the original
Changing a function in an existing asso ciation
These transformations are called covariant b ecause they covariantly change the initial typing en
vironment They are imp ortant b ecause covariantchange of the initial typing environmentgives
each expression the same or lesser typ e than the typ e given to that expression in the presence of
the original typing environment In a sense covariant transformations assure that all ob jects in the
program continue to conform to their original sp eci cations
Lo cal monotonicity de ned in Section is invariant with resp ect to covariant transformations
in the following sense if a new de nition is added it has to b e checked for lo cal monotonicity but no
old de nitions havetoberechecked This notion of invariance will b e used throughout this section
in the analysis of various asp ects of typ e consistency
Existence of a valid ranking for the user typ e graph de ned in Section is invariant with
resp ect to all covariant transformations except for typ e and subtyp e link additions Typ e and link
additions do not a ect existence of a valid ranking as long as the added typ es and links do not have
constraints and the added links do not intro duce new paths b etween typ es in the original graph
If any of the ab ove conditions are violated the existence of the valid ranking for the user typ e
graph needs to b e rechecked Note that since existence of the valid ranking is required for algorithm
termination but not for its correctness in some situations it may b e feasible to skip this checkas
long as there is a safeguard such as a time constraint that ensures termination of the typ e checker
Constraint consistency as de ned in Section is invariant with resp ect to covariant transfor
mations This follows from the prop erties of entailment discussed later in this section
Global b ehavior consistency Section describ es the conditions placed on the relationships
between argument and result typ es of di erent de nitions given for the same b ehavior It is based
on entailment and is therefore invariant with resp ect to covariant transformations
Functional consistency describ ed in Section is in a sense the typ echecking prop er as it checks
the conformance of the program to its sp eci cation Functional consistency is also entailment based
and thus invariant with resp ect to covariant transformations This is in contrast to ML style typ e
inference systems where a lo cal change in a function b o dy can p otentially a ect typing of other
functions in the program
Dispatch consistency conditions Section are invariant to all covariant transformations
except for subtyp e sup ertyp e link additions and b ehavior de nition asso ciation additions and
changes These conditions are the most volatile with resp ect to program transformations since they
are based on the notion of a concrete set which is in e ect a set of concrete typ e constructors below
agiven one Thus an addition of a subtyp e can change concrete sets for all its sup ertyp es and
thus violate dispatch consistency conditions The conservative approach to dispatch consistency
rechecking is as follows
If a subtyp e link is added let S b e the set of typ e constructors that acquire new concrete
typ e constructors as children as a result of this addition Then every b ehaviorthathastyp e
constructors from S in the primary form of the argument of at least one of its de nitions or
asso ciations has to b e fully rechecked for dispatch consistency Full rechecking here means
that al l de nitions and asso ciations for this b ehavior havetoberechecked
If a b ehavior de nition or asso ciation is added or its typ e is changed for a particular b ehavior
that b ehavior has to b e fully rechecked
Thus adding a subtyp e link at the b ottom of the hierarchy leads to full rechecking for a lot of
b ehaviors This is unfortunate and most probably unnecessary There are two p ossible approaches
to this problem The rst one is to create more precise rules ab out rechecking b ehaviors in this case
that would eliminate unnecessary rechecking in simple cases which are likely to constitute at least
of all b ehavior de nitions The second one is to ignore the p otential danger of not rechecking the
b ehaviors thus op ening the p ossibility of message not understo o d and message ambiguous errors
in the program that is build incrementally While this last approach clearly defeats the purp ose of
typ e checking it can b e practical in prototyping stage of program development when the p ossibility
of run time errors can b e traded for faster development time In this case the whole program will
havetoberechecked at the pro duction stage Other hybrid approaches are also p ossible
Most of the consistency checks describ ed ab ove are invariant with resp ect to covarianttyp e trans
formations b ecause they are based on the entailment algorithms of Section that pro duce results
invariant with resp ect to covariant transformations This follows from Lemma and Theorem
Note that the entailment testing algorithm could have b een made signi cantly faster but
still correct if it was allowed to use the attened form of the premises already computed on the
rst step for the construction of extended typ e graph However such mo di cation would lead to
the loss of invariance with resp ect to covariant transformations Consider the following example
Let the following de nitions b e given
type b covar X
type c covar X
type d
X d c X b X
These sp ecify that c b if d Let the entailmenttobechecked b e
c b d
The currententailment algorithm after verifying that c b will attempt to prove that
c a b a a d
in a typ e graph with an additional typ e constructor a and an additional subtyping relationship
c a b a This will fail as even a d is not true Thus the algorithm will conclude that
is not true
The mo di ed algorithm on the other hand will rst infer the attened form of c b
whichis
d
which is equivalentto
d
Thus the mo di ed algorithm will attempt to prove
a d
in a typ e system with an additional typ e constructor a and an additional subtyping relationship
a d This immediately succeeds and thus the mo di ed algorithm with conclude that is
true
Consider now the following covariant transformation of the original typ e system
type b covar X
type c covar X
type d
X d c X b X
type e
e b X
c X e
In other words a new typ e e was inserted b etween b and c Now the entailment is false
Indeed consider e Then
c c e e b e b
but
e d
Since b oth original and mo di ed algorithms are correct they return negativeanswer to
in this case Thus the mo di ed algorithm returns the result di erent from that returned for the
original typ e system and therefore the mo di ed algorithm is not invariant with resp ect to covariant
transformations
In this section the b ehavior of various stages of program veri cation with resp ect to covariant
program transformations was examined The conditions under which these stages do not haveto
b e rep eated for the mo di ed program have b een established The next section brie y discusses the
main engineering trade o s of the prop osed typ e system
Engineering trade o s
The expressivepower of this typ e system comes at a price First the prop osed typ e system is
signi cantly more complex than most of the typ e systems reviewed in Section The user is shielded
from this increased complexityby the layered design but a language implementor or database
designer would still have to cop e with it System uniformity and orthogonality will reduce the
necessary education time but it may still b e quite substantial
Second the uniform treatment of all the ob jects in the system also has its price tag Since every
entity including numbers characters strings etc is an ob ject and therefore can havebehaviors
that are dynamically dispatched on its typ e the typ e indicator su cient for dispatch purp oses has
to b e maintained at run time This has an impact on memory requirements
Third multiple dispatch utilized in this typ e system has a negative impact on execution p er
formance Even in the presence of e cientmulti metho d dispatchtechniques multiple dispatchis
still inherently slower than single dispatch However a go o d optimizing compiler can p otentially
optimize away most of the necessary dynamic metho d dispatchby carefully analyzing the context
of the call sites or their run time prop erties as demonstrated in DGC DDG HU
In the next section the brief summary of the imp ortant features of the theory develop ed in this
chapter will b e presented
Summary
The approachtaken in this chapter can b e summarized as follows The program is analyzed to yield
asetofconstrainedtypes and relationships b etween them These relationships are translated into
sets of subtyping constraints A program typ echecks if these sets admit a solution This solution
do es not have to b e found since mere fact of its existence is su cient to ensure run time correctness
Thus the algorithms attempt to nd inconsistencies in the given constraint sets rather than nd their
solution The constraints are interpreted in the domain of regular trees equipp ed with a subtyping
relationship and lower and upp er b ound op erators
The main features of the presented theory are
Inclusion p olymorphism substitutability
Parametric p olymorphism
Partial typ e inference only b ehavior typ es need to b e explicitly sp eci ed
Provable decidability and correctness
Explicit typ e constraints
Supp ort for union and intersection typ es
Mo dularity primitive functions and store semantics can b e easily mo di ed
Supp ort for imp erativetyp es
Supp ort for typ e system evolution covariant transformations
The ability to deal with subtyping b etween typ es of di erentvariances
Supp ort for distinction b etween b ehavior de nitions and asso ciations
Dispatchgranularity di erent from the typ e sp eci cation granularity
This concludes the presentation of the typ e system theory Inthischapter decidabilityand
correctness of the algorithms and techniques presented in Chapter has b een proven The e ect of
various semantical extensions on the theory and the algorithms has b een considered Issues related
to the typ e system evolution and its e ect on typ echecking were also discussed Finally a summary
of the ma jor theoretical features of the presented typ e system has b een given The review of various
theoretical typ e systems has b een presented earlier in Section The next chapter concludes the
dissertation and discusses its main contributions as well as directions for future research
Chapter
Conclusions
Summary and contributions
In this dissertation a typ e system for an ob ject oriented programming language has b een develop ed
Analysis of theoretical and practical requirements placed on the typ e system by the language and
database comp onents of the system was p erformed to yield a set of requirements the typ e system
should satisfy Anumb er of existing and prop osed typ e systems have b een examined and evaluated
from the p oint of view of these requirements This extensive analysis is the rst contribution of
this dissertation as it covers a very broad sp ectrum of typ e systems yet evaluates them from the
same uniform standp oint the set of requirements obtained by the previous analysis It is shown
that for each required feature there is at least one typ e system that has it However the desired
combination of features remains elusiveinthatnotyp e system theoretical or practical existing in
a programming language or prop osed has all the features necessary for the consistent and uniform
treatment of ob ject oriented database programming
Based on these requirements a typ e system is designed and various asp ects of it are discussed
This feature rich design of the typ e system is the second contribution of this work The design pro cess
yields a consistent and uniform typ e system that satis es the requirements develop ed earlier and
successfully passes the tests from the typ e system expressibility test suite The main design features
of the develop ed typ e system are consistentcombination of parametric and inclusion p olymorphism
an elab orate and precise mechanism for b ehavior message typing handling of precise and complex
typ es of database query op erations uniform integration of imp erative features provisions for schema
evolution and a clean separation b etween interface implementation co de and representation
data layout The three layer typ e system design provides additional exibility in sp eci cation
and use of typ es and facilitates b etter co de reuse A ma jor motivation for the layered design is
understandability and usabilityofthetyp e system by programmers The system can b e used at
all the three layers the deep er the layer the more p ower it provides and the greater complexityit
involves
The designed typ e system is used in a prototyp e ob ject oriented programming language termed
source language throughout this dissertation This language is more then just a testb ed for the
develop ed typ e system it is p owerful enough to describ e all the ma jor comp onents of ob ject oriented
programming and design including typ e and function sp eci cation and veri cation handling of
dynamic and imp erativetyp es and ob jects of these typ es multiple dispatch separation b etween
b ehavior declarations and de nitions on b oth the typ e and implementation level and enco ding of
database queries via precisely typ ed b ehavior applications This source language can b e used as a
core of a real ob ject oriented database programming language as it includes the dispatch pro cedure
for multiple dispatch of b ehaviors de ned in the language A program written in the source language
is veri ed by rst translating it into a more theoretical and simpli ed target language and then
applying the typ echecking techniques and veri cation pro cedures to the resulting program The
main typ echecking algorithms functional consistency checking are local in that a co de change
inside a function b o dy do es not a ect the typing or validity of the other functions in the program
The third contribution of this dissertation is the development of the source language along with the
algorithms and pro cedures for veri cation and typ echecking of the programs written in it
Finally a theory has b een develop ed to rigorously provethevalidity of the presented typ echecking
mechanisms This theory includes a mo del of typ es as regular trees formal treatment of subtyping
constrainttyp es and entailment It also includes a natural semantics of the target language designed
to formalize and reason ab out its run time prop erties Both algorithm termination and sub ject
reduction have b een proven The theory was develop ed in a mo dular fashion so as to allow its
application to other languages and systems The pro of of the validity of the handling of imp erative
typ es in the target language was presented as a non trivial example of utilization of the p ower
inherent in this mo dular approach The theory was further examined by lo oking at the ways it
can b e extended to supp ort semantic extensions needed for a full edged programming language
Another p oint of discussion was related to the b ehavior of the presented algorithms in the presence of
typ e system changes An imp ortant class of typ e system transformations covariant transformations
has b een identi ed and their impact on typ echecking and program veri cation has b een carefully
examined The theory has thus b een shown to b e mo dular extensible and incremental to a certain
degree The develop ed theory also supp orts all ma jor typ e system and design features of the source
and target language including parametric and inclusion p olymorphism imp erative union and
intersection typ es typ e constraints avery lib eral notion of subtyping di erent granularity for typ e
and dispatch sp eci cations and separation b etween interface typ e and implementation co de It
also features partial typ e inference that is known to reduce the burden of writing typ e annotations
for every ob ject in a program At the same time typ e inference is lo calized in order to contain
the e ect of function co de mo di cations The developmentofthistyp e theory and the pro ofs of
decidability and correctness of the typ echecking algorithms are the fourth ma jor contribution of this
dissertation
Future research
While signi cantwork has b een done to achieve the primary goal of this dissertation there is still
a considerable ro om for future research
On the practical side making the main veri cation algorithms more e cient is quite imp ortant
While the algorithms presented herein are correct the main entailment algorithm app ears to b e
exp onential and thus needs to b e improved up on b efore it can b e used in a practical language
Implementation of the source and target languages as well as an e cient implementation of trans
lation and veri cation algorithms remain to b e accomplished Another interesting and promising
researchvenue is related to the development of an e cient dispatch strategy at a ner granularity
In this dissertation the dispatch on parametric typ es do es not dep end on typ e parameter This
is done to utilize the existing e cientmulti metho d dispatchtechniques However if an e cient
mechanism capable of taking into accounttyp e parameters can b e develop ed it will greatly simplify
the theory and make the language more p owerful Finally development of a database programming
language based on this typ e system presents a whole new set of challenges such as the semantics of
p ersistence handling of p ersistenttyp es b ehaviors and functions and e cient implementationof
database queries and up dates
From the design prosp ective addition of exceptions into the language seems to b e an interesting
and p otentially rewarding research direction Another design p ossibilityworth pursuing is the addi
tion of a mo dule system to the source language From the database prosp ective adding transaction
supp ort directly into the language seems to b e a promising idea Yet another interesting research
direction is incorp oration of algebraic types typ e constructors that serve alsoasvalue constructors
as in Standard ML MTH into the typ e system
From the theoretical p oint of view there are a numb er of issues that warrant further study One
of the most imp ortant theoretical research directions is a study into the p ossibility of lifting or sig
ni cantly relaxing the valid ranking requirementplacedontheusertyp e graph The author b elieves
it can b e accomplished without sacri cing decidability Another theoretical research p ossibilityis
researchinto the complexity of the presented algorithms and its theoretical limits Finally develop
ment of the full edged language semantics with continuations and the necessary mo di cation of
the relevantproofsisachallenging task
The last task is just one of the integral parts of a larger problem of developing a p owerful
theoretically sound e cient and practical ob ject oriented database programming language for the
next millennium I b elievesuchadevelopment will b e undertaken and the result will probably
exceed the exp ectations of b oth research and industrial communities My hop e is that the research
presented in this dissertation is a step along this long and di cult road
Bibliography
AB M P Atkinson and O P Buneman Typ es and p ersistence in database programming
languages ACM Computing Surveys June
ABD M Atkinson F Banchilon D DeWitt K Dittrich D Maier and S Zdonik The
ob ject oriented database system manifesto In F Banchilon C Delob el and P Kanel
lakis editors Building an Object Oriented Database System The Story of O
AC R M Amadio and L Cardelli Subtyping recursivetyp es ACM Transactions on
Programming Languages and Systems
AC M Abadi and L Cardelli ATheory of Objects Monographs in Computer Science
Springer
ACO A Albano L Cardelli and R Orsini Galileo A strongly typ ed interactive conceptual
language ACM Transactions on Database Systems June
Ada Ada Reference Manual Available electronically
URL http www adahome com rm
ADL R Agrawal L G DeMichiel and B G Lindsay Static typ e checking of multi metho ds
ACM SIGPLAN Notices Novemb er In Pro c of OOPSLA
AFM O Agesen S N Freund and J C Mitchell Adding typ e parametrization to the Java
language In Proceedings of the OOPSLA
AG R Agrawal and N H Gehani ODE ob ject database and environment The lan
guage and the data mo del In Proceedings of the ACM SIGMOD International
Conference on Management of Data pages
AG K Arnold and J Gosling The Java Language Speci cation Addison Wesley th
edition ISBN
AGO A Albano G Ghelli and R Orsini Fib onacci A programming language for ob ject
databases VLDB Journal
AM M Atkinson and R Morrison Orthogonally p ersistent ob ject systems VLDB Journal
AN A Arnold and M Nivat The metric space of in nite trees Algebraic and top ological
prop erties Fundamenta Informaticae III pages
App A W App el A critique of standard ML Technical Rep ort CS TR Princeton
University November
App Apple Computer Inc Dylan Interim Reference Manual
AVWW J Armstrong R Virding C Wikstr om and M Williams Concurrent Programming
in Erlang Prentice Hall nd edition
AW A AikenandE L Wimmers Typ e inclusion constraints and typ e inference Technical
Rep ort RJ IBM Research Division August
AWL A Aiken E L Wimmers and T K Lakshman Soft typing with conditional typ es
In ConferenceRecord of POPL st ACM SIGPLAN SIGACT Symposium on
Principles of Programming Languages pages ACM Press
BBdB R Bal H Balsters R A de By A Bosschaart J Flokstra M V Keulen
J Skowronek and B Termorshuizen The TM Manual Decemb er Version
revision C Available electronically
URL ftp ftp cs utwente nl pub doc TM
BC J Boyland and G Castagna Typ e safe compilation of covariant sp ecialization A
practical case Technical Rep ort UCB CSD University of California Computer
Science Division EECS Berkeley California Novemb er
BC J Boyland and G Castagna Parasitic metho ds An implementationofmulti metho ds
in Java SIGPLAN Notices Pro ceedings of OOPSLA
URL ftp ftp ens fr pub dmi users castagna oopsla ps gz
BCC K Bruce L Cardelli G Castagna The Hopkins Ob ject Group G Leavens and
B Pierce On binary metho ds Theory and Practice of Object Systems
BDG D G Bobrow L G DeMichiel R P Gabriel S E Keene G Kiczales and D A
Mo on Common Lisp Ob ject System sp eci cation June X J Do cument
R
BDMN G M Birtwistle O J Dahl B Myhrhaug and K Nygaard Simula Begin Studentlit
teratur Lund Sweden Bratt Institute Fuer Neues Lerned Go ch FRG Chartwell
Bratt Ltd Kent England
BFP K B Bruce A Fiech and L Petersen Subtyping is not a go o d match for ob ject
oriented languages In Informal Proceedings of The Fourth Workshop on Foundations
of Object OrientedLanguages FOOL Contributed talk
BG G Bracha and D Griswold Strongtalk Typ echecking Smalltalk in a pro duction
environment In Proceedings of the ACM Conference on Object OrientedProgramming
Systems Languages and Applications
BG M F Barrett and M E Giguere A note on covariance and contravariance uni cation
ACM SIGPLAN Notices January
BLR G Baumgartner K L aufer and V F Russo Interaction of ob ject oriented design
patterns and programming languages Technical Rep ort CSD TR Deptartment
of Computer Sciences Purdue University
BM a F Bourdoncle and S Merz Typ e checking higher order p olymorphic multi metho ds
In Proceedings of the th ACM Conference on Principles of Programming Languages
POPL
BM b F Bourdoncle and S Merz Primitivesubtyping implicit p olymorphism ob ject
orientation In Foundations of Object OrientedLanguages Extended abstract
BO P Buneman and A Ohori Polymorphism and typ e inference in database programming
ACM Transactions on Database Systems March
BOSW a G Bracha M Odersky D Stoutamire and P Wadler GJ Extending the Javapro
gramming language with typ e parameters Manuscript March Revised August
BOSW b G Bracha M Odersky D Stoutamire and P Wadler GJ sp eci cation Manuscript
May
BOSW c G Bracha M Odersky D Stoutamire and P Wadler Making the future safe for
the past Adding genericitytotheJava programming language In Proceedings of the
th Annual ACM SIGPLAN Conference on Object OrientedProgramming Systems
Languages and Applications OOPSLA pages Octob er
BOW K B Bruce M Odersky andP Wadler A statically safe alternativetovirtual
typ es In Proceedings of the European Conference on Object OrientedProgram
ming ECOOP
BP A Black and J Palsb erg Foundations of ob ject oriented languages ACM SIGPLAN
Notices Workshop Rep ort
BP P Buneman and B Pierce Union typ es for semistructured data Technical Rep ort
MS CIS DepartmentofCIS UniversityofPennsylvania
Bra G Bracha The Programming Language Jigsaw Mixins Modularity And Multiple
Inheritance PhD thesis University of Utah Department of Computer Science March
Bru K K Bruce Typing in ob ject oriented languages Achieving expressibility and safety
URL ftp cs williams edu pub Kim Static ps
BSG K B Bruce A Schuett and R V Gent A typ e safe p olymorphic ob ject oriented
language Accessible byanonymous FTP July
URL ftp cs williams edu pub kim PolyTOIL dvi
BSG K B Bruce A Schuett and R V Gent PolyTOIL A typ e safe p olymorphic ob ject
oriented language In W Oltho editor Proceedings of the th European Conference
on Object OrientedProgramming ECOOP Aarhus Denmark August LNCS
Springer Extended abstract
Car a L Cardelli Amb er In G Cousineau P L Curien and B Robinet editors Combina
tors and Functional Programming Languages Springer Verlag LNCS
Car b L Cardelli A p olymorphic calculus with Typ e Typ e Technical Rep ort DEC
SRC Lytton Avenue Palo Alto CA May SRC Research Rep ort
Car L Cardelli A semantics of multiple inheritance Information and Computation
Car L Cardelli Typ eful programming In E J Neuhold and M Paul editors Formal
Description of Programming Concepts IFIP State of the Art Rep orts Series Springer
Verlag February
URL http www luca demon co uk Bibliography html
Car L Cardelli An implementation of F Technical Rep ort DEC Systems Research
Center February
Car L Cardelli Typ e systems In A B Tucker editor The Computer Science and Engi
neering Handbook chapter CRC Press
URL http www luca demon co uk Bibliography html
Cas a G Castagna Covariance and contravariance Con ict without a cause ACM Trans
actionsonProgramming Languages and Systems May
Cas b G Castagna A meta language for typ ed ob ject oriented languages Theoretical Com
puter Science November
Cas G Castagna Object OrientedProgramming A Uni edFoundation chapter Typ e
Systems for Ob ject Oriented Programming Progress in Theoretical Computer Science
Birka uzer Boston
CBB R G G Cattell D Barry D Bartels M Berler J Eastman S Gamerman D Jordan
A Springer H Strickland and D Wade The Object Database Standard ODMG
Morgan Kaufmann Publishers Los Altos CA USA
CCH P Canning W Co ok W Hill W Oltho and J C Mitchell F b ounded p olymor
phism for ob ject oriented programming In Proceedings of the ACM Conferenceon
Functional Programming and Computer Architecture pages
CGL G Castagna G Ghelli and G Longo A calculus for overloaded functions with sub
typing Information and Computation February
Cha a C Chamb ers The Design and Implementation of the SELF Compiler an Optimizing
Compiler for Object OrientedProgramming Languages PhD thesis Stanford Univer
sity March
Cha b C Chamb ers Ob ject oriented multi metho ds in Cecil In O L Madsen editor ECOOP
European Conference on Object OrientedProgramming Utrecht The Netherlands
volume of Lecture Notes in Computer Science pages Springer Verlag New
York N Y
Cha C Chambers The Cecil language Sp eci cation and rationale Technical Rep ort
TR Department of Computer Science and Engineering FR Universityof
Washington March
CL C Chamb ers and G T Leavens Typ echecking and mo dules for multimetho ds ACM
Transactions on Programming Languages and Systems November
CL C Chamb ers and G T Leavens BeCecil A core ob ject oriented language with blo ck
structure and multimetho ds Semantics and typing Technical Rep ort Depart
ment of Computer Science Iowa State University Decemb er
CL C Chamb ers and G T Leavens BeCecil A core ob ject oriented language with blo ck
structure and multimetho ds Semantics and typing In FOOL The Fourth Interna
tional Workshop on Foundations of Object OrientedLanguages Paris France January
CMM R C H Connor D J McNally and R Morrison Subtyping and assignmentin
database programming languages In Proceedings of the rd International Workshop
on Database Programming Languages Nap lon Greece
CMMS L Cardelli S Martini J C Mitchell and A Scedrov An extension of system F with
subtyping In T Ito and A R Meyer editors International Conference on Theoretical
Aspects of Computer Software pages Lecture Notes in Computer Science
CO K Chen and M Odersky Atyp e system for a lamb da calculus with assignment In
Proc Theoretical Aspects of Computer Science Sendai Japan April Spinger
LNCS
Cou B Courcelle Fundamental prop erties of in nite trees Theoretical Computer Science
Cou B Courcelle Equivalence and transformation of regular systems applications to
recursive program schemes and grammars Theoretical Computer Science
CT W Chen and V Turau Multiple dispatching based on automata Journal of Theory
and Practice of Object Systems
CTK W Chen V Turau and W Klas E cient dynamic lo ok up strategy for multi metho ds
In M Tokoro and R Pareschi editors ECOOP European Conference on Object
OrientedProgramming volume of Lecture Notes in Computer Science pages
New York N Y July Springer Verlag
DAS E Dujardin E Amiel and E Simon Fast algorithms for compressed multi metho d dis
patch tables generation ACM Transactions on Programming Languages and Systems
DCG J Dean C Chamb ers and D Grove Identifying pro table sp ecialization in ob ject
oriented languages Technical Rep ort Department of Computer Science and
Engineering FR UniversityofWashington February
DDG J Dean G DeFouw D Grove V Livinov and C Chamb ers Vortex an optimiz
ing compiler for ob ject oriented languages ACM SIGPLAN Notices
Octob er
DE S Drossop oulou and S Eisenbach Javaistyp e safe probably InProceedings of the
th European ConferenceonObject OrientedProgramming ECOOP June
DGC J Dean D Grove and C Chamb ers Optimization of ob ject oriented programs using
static class hierarchy analysis In W Oltho editor Proceedings of the th European
Conference on Object OrientedProgramming ECOOP Aarhus Denmark August
LNCS Springer
DGLM M Day R Grub er B Liskov and A C Myers Subtyp es vs where clauses Constrain
ing parametric p olymorphism SIGPLAN Notices Octob er
EST a J Eifrig S Smith and V Trifonov Sound p olymorphic typ e inference for ob jects
SIGPLAN Notices Octob er
EST b J Eifrig S Smith and V Trifonov Typ e inference for recursively constrained typ es
and its application to OOP Electronic Notes in Theoretical Computer Science
URL http www elsevier nl locate entcs volume html
ESTZ J Eifrig S Smith V Trifonov and A Zwarico An interpretation of typ ed OOP in a
language with state LISP and Symbolic Computation
FM K Fisher and J C Mitchell The developmentoftyp e systems for ob ject oriented
languages Theory and Practice of Object Systems
URL ftp theory stanford edu pub jcm papers tapos ps
Fra M Franz The programming language Lago ona A fresh lo ok at ob ject orientation
Software Concepts and Tools
Ghe G Ghelli A static typ e system for message passing ACM SIGPLAN Notices
Novemb er In Pro c of OOPSLA
GM A Gawecki and F Matthes Integrating subtyping matching and typ e quanti cation
A practical p ersp ective In Proceedings of the th European Conference on Object
OrientedProgramming Linz Austria July Springer Verlag
GR A Goldb erg and D Robson ST The Language Addison Wesley
Har S P Harbison Modula Prentice Hall
Hau F J Hauck Towards the implementation of a uniform ob ject mo del In A Bo de and
M D Cin editors Paral lel Computer Architectures Theory Hardware Software and
Applications SFB Col loquium SFB and SFB numb er in Lecture Notes
in Computer Science pages Springer Octob er
HJW P Hudak S P Jones P Wadler B Boutel J Fairbairn J Fasel M M Guzm an
K Hammond J Hughes T Johnsson D Kieburtz R Nikhil W Partain and J Peter
son Report on the Programming Language Haskel l March Version Available
electronically
URL http www haskell org definition haskell report ps gz
HLPS W Holst Y Leontiev C Pang and D Szafron Multi metho d dispatch using pro duct
typ e tries Technical Rep ort TR University of Alb erta
Hol a W Holst Mo dular Smalltalk A rst implementation Technical Rep ort TR
Department of Computing Science University of Alb erta
H ol b U H olzle Integrating indep endently develop ed comp onents in ob ject oriented lan
guages In Proceedings of ECOOP
HSPL W Holst D Szafron C Pang and Y Leontiev Multi metho d dispatch using single
receiver pro jections Technical Rep ort TR University of Alb erta
HU U H olzle and D Ungar Reconciling resp onsiveness with p erformance in pure ob
ject oriented languages ACM Transactions on Programming Languages and Systems
July
IEE IEEE standard for binary oating p oint arithmetic ANSI IEEE Standard
Institute of Electrical and Electronics Engineers August
JW K Jensen and N Wirth The Programming Language Pascal Springer Verlag
KCMS G N C Kirby R C H Connor R Morrison and D Stemple Using re ection to sup
port typ e safe evolution in p ersistent systems Technical Rep ort CS University
of St Andrews
Kim W Kim Ob ject oriented database systems Promises reality and future In Proceed
ings of the th VLDB Conference pages
KT W Klas and V Turau Persistence in the ob ject oriented database programming lan
guage VML Technical Rep ort TR International Computer Science Institute
Center St Suite Berkeley CA July
LCD B Liskov D Curtis M Day S Ghemawat R Grub er P Johnson and A C Meyers
Theta Reference Manual MIT Lab oratory for Computer Science Cambridge MA
February
URL http www pmg lcs mit edu papers thetaref
Lit V Litvinov Constraint based p olymorphism in Cecil Towards a practical and static
typ e system In Proceedings of the ConferenceonObject OrientedProgramming
Systems Languages and Applications OOPSLA
LM G T Leavens and T D Millstein Multiple dispatchasdispatchontuples InPro
ceedings of the Conference on Object OrientedProgramming Systems Languages and
Applications OOPSLA pages Octob er
URL http www cs washington edu homes todd papers oopsla ps
LML V G Lutiy A B Merkov Y V Leontiev E J Gawrilow N A Ivanova M E
Io nova M L Paklin and A K Ho dataev DBMS Modula K RAN Data Pro cessing
Center Moscow in Russian Sistema Programmirovaniya Baz Dannyh Mo dula
K
LOS Y Leontiev M T Ozsu and D Szafron On separation b etween interface implemen
tation and representation in ob ject DBMSs In Proceedings of TOOLS Santa
Barbara California August
LP W R LaLonde and J Pugh Sub classing subt yping is a Journal of Object
OrientedProgramming January
LRV C L ecluse P Richard and F V elez O an ob ject oriented data mo del In F Ban
chilon C Delob el and P Kanellakis editors Building an Object OrientedDatabase
System The Story of O
LW B Liskov and J M Wing A b ehavioral notion of subtyping ACM Transactions on
Programming Languages and Systems November
LW G T Leavens and W E Weihl Sp eci cation and veri cation of ob ject oriented pro
grams using sup ertyp e abstraction ACTA Informatica November
MBC R Morrison F Brown R Connor Q Cutts A Dearle G Kirby and D Munro
Napier Reference Manual University of St Andrews March Release
MBL A C Myers J A Bank and B Liskov Parameterized typ es for Java In Proceedings
of the th ACM Simposium on Principles of Programming Languages POPL
January
Mey B Meyer Ei el the language Prentice Hall
MHH W B Mugridge J Hamer and J G Hosking Multi metho ds in a statically typ ed
programming language In P America editor ECOOP pages Geneva
Switzerland July LNCS
MMPN O L Madsen B M ller Pedersen and K Nygaard Object OrientedProgramming in
the BETAProgramming Language Addison Wesley ISBN
MMS F Matthes S Mu ig and J W Schmidt Persistent p olymorphic programming in
Tyco on An intro duction FIDE Technical Rep ort Series FIDE Department
of Computing Sciences University of Glasgow Glasgow G QQ August
MS F Matthes and J Schmidt Bulk typ es Built in or add on In Proceedings of the
Third International Workshop on Database Programming Languages Morgan Kauf
mann Publishers September
MS F Matthes and J Schmidt De nition of the Tyco on language a preliminary rep ort
Technical Rep ort FBI HH B Universit at Hamburg Octob er
MTH R Miller M Tofte and R Harp er The De nition of StandardML MIT Press
MW H M ossenb ok and N Wirth The programming language Ob eron Manuscript
Octob er Institut fur Computersysteme ETH Zuric h
MW S MarlowandP Wadler A practical subtyping system for Erlang In Proceedings
of the Second International ConferenceonFunctional Programming Amsterdam June
NP O Nierstrasz and M Papathomas Towards a typ e theory for active ob jects ACM
OOPS Messenger April Pro ceedings of the OOPSLA ECOOP
Workshop on Ob ject Based Concurrent Systems
OBBT A Ohori P Buneman and V Breazu Tannen Database programming in Machiavelli
a p olymorphic language with static typ e inference SIGMOD Record
OL M Odersky and K L aufer Putting typ e annotations to work In Proc rdACM
Symposium on Principles of Programming Languages pages January
OPS M T Ozsu R J Peters D Szafron B Irani A Lipka and A Munoz TIGUKAT A
uniform b ehavioral ob jectbase management system The VLDB Journal
July
OW M Odersky and P Wadler Pizza into Java Translating theory into practice In
Proceedings of the th ACM Simposium on Principles of Programming Languages
POPL January
Pet R J Peters TIGUKAT A uniform b ehavioral ob jectbase management system Tech
nical Rep ort TR Department of Computing Science University of Alb erta April
PHLS C Pang W Holst Y Leontiev and D Szafron Multi metho d dispatch using multi
ple row displacement In Proceedings of the European Conference on Object Oriented
Programming ECOOP
Pot F Pottier Simplifying subtyping constraints ACM SIGPLAN Notices
June
Pot F Pottier Type InferenceinthePresence of Subtyping from Theory to Practice PhD
thesis Universit eParis VI I April
PS J Palsb erg and M I Schwartzbach Object OrientedTypeSystems John Wiley
Sons
QKB Z Qian and B Krieg Brueckner Typ ed OO functional programming with late binding
In P Cointe editor Proceedings of the th European Conference on Object Oriented
Programming volume of LNCS pages Springer July
RCS J E Richardson M J Carey and D T Schuh The design of the E programming
language ACM Transactions on Programming Languages and Systems
July
Reh J Rehof The Complexity of Simple Subtyping Systems PhD thesis DIKU Department
of Computer Science University of Cop enhagen
RS P Ro e and C Szyp erski Lightweight parametric p olymorphism for Ob eron In Pro
ceedings of the Joint Modular Languages Conference
RTL R K Ra j E Temp ero H M Levy A P Black N C Hutchinson and E Jul Emerald
A general purp ose programming language SoftwarePractice and Experience
January
RW M Reiser and N Wirth Programming in Oberon Steps beyond Pascal and Modula
Addison Wesley
Sar V Saraswat Javaisnottyp e safe Available electronically
URL http www research att com vj bug html
Seq D Sequeira TypeInference with Bounded Quanti cation PhD thesis Departmentof
Computer Science UniversityofEdinburgh Also Technical Rep ort ECS LFCS
Sha D Shang Transframe The AnnotatedReference Software Systems Research Lab ora
tory Motorola Inc Schaumburg Illinois January Draft
SM J W Schmidt and F Matthes The DBPL pro ject Advances in mo dular database
programming Information Systems
SO D Stoutamire and S Omohundro The Sather sp eci cation Technical Rep ort
TR International Computer Science Institute at Berkeley August
Str B Stroustrup The C Programming Language Addison Wesley
Tai A Taivalsaari On the notion of inheritance ACM Computing Surveys
Septemb er
Tho K K Thorup GenericityinJava with virtual typ es In Proceedings of the
European Conference on Object OrientedProgramming ECOOP
TNG D Tsichritzis O Nierstrasz and S Gibbs Beyond ob jects Ob jects International
Journal of Intel ligent and Cooperative Information Systems March
TS V Trifonov and S Smith Subtyping constrained typ es In Proceedings of the rd
International Static Analysis Symposium pages May Lecture Notes in
Computer Science
TT L Thorup and M Tofte Ob ject oriented programming and Standard ML In J H
Reppy editor Record of the ACM SIGPLAN Workshop on ML and its Applica
tions Orlando Florida numb er in Rapp ort de recherche pages INRIA
June
Tur A M Turing Computabilityand de nability Journal of Symbolic Logic
Wir N Wirth Programming in Modula Springer Verlag nd edition
Wri A K Wright Polymorphism for imp erative languages without imp erativetyp es Tech
nical Rep ort TR Department of Computer Science Rice University February
App endix A
The Basic TIGUKAT Typ e System
This chapter gives a full description of the basic TIGUKATtyp e system Classes and implementation
typ es are not fully describ ed as their details are implementation sp eci c
A Common b ehaviors
behavior typeOf X T ConstrainedType Object type
behavior classOf X T InfiniteClass X Object class
behavior itypeOf X T ImplementationType Object implementation type
behavior OIDequal X X T Boolean Object identity equality
behavior equal X x X y T Boolean Equality
Shortcut operator binary
implementation return x OIDequal y
notEqual X x X y T Boolean Inequality
Shortcut operator binary
implementation return not x y
print X OutputStream X Print to an output stream
apply X X Y Y Function application
Shortcuts operator binary
juxtaposition
A Pro duct typ es
type T Unit
type T ProductN covar X covar X covar XN
project X
project X
projectN XN
for each N greater than
A Functional typ es
type T Function contravar A covar R
nargs T Natural number of arguments
code T String function code may be empty
class C Function implements T Function A R
type T Behavior contravar A covar R subtype of T Function A R
name T String behavior name
description T String Documentation
definitions T ConstrainedType all definitions
associations T Set T BehaviorAssociation A R all associations
dispatch T List T Type T Function A R dispatch
class C Behavior implements T Behavior A R
The typ e T Function A R can b e abbreviated as A R or as A R The following is the typ e
necessary for b ehavior typ e de nition
type T BehaviorAssociation contravar A covar R subtype of T Object
type T SimpleConstrainedType type
function T Function A R associated function
class C BehaviorAssociation implements T BehaviorAssociation A R
The following is the typ e of low level implementation functions
type T ImplementationFunction subtype of T Object
description T String Documentation
declaration T String host language declaration
definition T String host language definition
argtype T List T ImplementationType required implementation types
of all arguments
class C ImplementationFunction implements T ImplementationFunction
A Ob ject typ es
A Sp ecial typ es
type T Object
type T Null subtype of all object types
class C Null implements T Null
A Atomic typ es
type T Discrete subtype of T Object
pred selftype Return the previous element
succ selftype Return the next element
type T PartiallyOrdered contravar X subtype of T Object
less selftype T Boolean Antisymmetric comparison
Shortcut operator binary
greater selftype x T Boolean Antisymmetric comparison
Shortcut operator binary
implementation return x self
lessOrEqual selftype x T Boolean Symmetric comparison
Shortcut operator binary
implementation return x self or x self
greaterOrEqual selftype x T Boolean Symmetric comparison
Shortcut operator binary
implementation return x self
type T Ordered contravar X subtype of T PartiallyOrdered X
max selftype x selftype Maximum of the two
implementation
return if x self then self else x endif
min selftype x selftype Minimum of the two
implementation
return if x self then x else self endif
type T Numeric subtype of T Ordered T Numeric
abs T Numeric Absolute value
negate T Numeric Negation
Shortcut operator unary
add T Numeric T Numeric Addition
Shortcut operator binary
subtract T Numeric T Numeric Subtraction
Shortcut operator binary
multiply T Numeric T Numeric Multiplication
Shortcut operator binary
divide T Numeric T Numeric Division
Shortcut operator binary
type T Boolean subtype of T Object
not T Boolean Negation
or T Boolean T Boolean Logical OR
Shortcut operator binary or
and T Boolean T Boolean Logical AND
Shortcut operator binary and
xor T Boolean T Boolean Logical XOR
Shortcut operator binary xor
if X X X If expression Shortcut
if then else endif
finite class C Boolean implements T Boolean
implementation type short atomic int
not implementation function
not int self return self
or C Boolean implementation function
and int self int x return self x
type T Character subtype of T Discrete T Ordered T Character
ord T Natural Returns the ordinal value
finite class C ASCIICharacter implements T Character
implementation type short atomic char
finite class C UnicodeCharacter implements T Character
implementation type short atomic Unichar
type T Real subtype of T Numeric
truncate T Integer Truncate throwing away
the fractional part
round T Integer Round to the nearest
sign T Integer Sign if positive if
negative otherwise
Refined from T Numeric
abs T Real
negate T Real
add T Real T Real
subtract T Real T Real
multiply T Real T Real
divide T Real T Real
infinite class C Real implements T Real
implementation type short atomic float
infinite class C LongReal implements T Real
implementation type long atomic double
type T Integer subtype of T Real T Discrete
div T Integer T Integer Integer division
Refined from T Real
abs T Natural
negate T Integer
add T Integer T Integer
subtract T Integer T Integer
multiply T Integer T Integer
infinite class C Integer implements T Integer
implementation type short atomic int
infinite class C LongInteger implements T Integer
implementation type long atomic long int
type T Natural subtype of T Integer
mod T Natural T Natural Remainder
Refined from T Integer
truncate T Natural
round T Natural
sign T Natural
div T Natural T Natural
add T Natural T Natural
multiply T Natural T Natural
infinite class C Natural implements T Natural
implementation type short atomic unsigned
infinite class C LongNatural implements T Natural
implementation type long atomic long unsigned
A Collection typ es
type T Collection covar X subtype of T Object
hasElement X T Boolean Checks if the element
is in the collection
cardinality T Natural Collection cardinality
pick X Pick an element
map X Y T Collection Y Apply the given function to all
elements and return the
collection of results
filter X T Boolean T Collection X Filters the receiver
collection using the
argument function as a filter
sort where X subtype of T Ordered X T List X Sorts
the elements of the
collection Only applicable to
collections of ordered elements
sort X X T Boolean T List X Sorts the collection using
the supplied sorting function
type T Set covar X subtype of T Collection X
subset T Set Y T Boolean Is the receiver a subset
of the argument
union T Set Y T Set lub X Y Set union
intersect T Set Y T Set glb X Y Set intersection
difference T Set Y T Set X Set difference
addElement X T Set X Add an element
removeElement Y T Set X Remove an element
Refined from T Collection
map X Y T Set Y
filter X T Boolean T Set X
infinite class C Set implements T Set X
const T List X list
type T EmptySet subtype of T Set X
finite class C EmptySet implements T EmptySet
type T USet novar X subtype of T Set X
union T Set X Destructive set union
intersect T Set Y Destructive set intersection
difference T Set Y Destructive difference
addElement X Destructively add an element
removeElement Y T Boolean Destructively remove an element
Returns if it was removed
removeAll Remove all elements
map X X Replace all objects in the set by their images
obtained by application of the given function
manual class C USet implements T USet X
const T Array X array
type T List covar X subtype of T Collection X
at T Natural X Get at arg s position
cat X T List X Concatenation
slice T Natural T Natural T List X Slice from i th
to j th element
Refined from T Collection
map X Y T List Y
filter X T Boolean T List X
infinite class C List implements T List X
type T EmptyList subtype of T List X
finite class C EmptyList implements T EmptyList
type T Array novar X subtype of T List X
Refined from T List
at T Natural X Set at arg s position
slice T Natural T Natural T List X Slice set
manual class C Array implements T Array X
type T String subtype of T List T Character
Refined from T List
cat T String T String
slice T Natural T Natural T String
filter T Character T Boolean T String
infinite class C String implements T String
infinite class C UnicodeString implements T String
A Imp erativetyp es
type T Var novar X subtype of T Object
get X Get the value
set X Set the value
destructive X X See the note below
manual class C Var X implements T Var X
The b ehavior destructive is designed to replace the value stored in the variable by the value
generated from the old contents of that variable by the function passed in as an argument In other
words
v destructive f
is equivalentto
v set v get f
For example
Integer v
v
v destructive negate
v print stdout
will print while
Integer v
v
v destructive fun x return x plus
v print stdout
will print
A Metatyp es
type T ConstrainedType subtype of T PartiallyOrdered T ConstrainedType
components T Set T SimpleConstrainedType Components of this type
type T SimpleConstrainedType subtype of T ConstrainedType
constraints T Set T TypeConstraint Constraints placed on this type
variables T Set T TypeVariable Set of type variables
root T OpenTypeOrTV Root of the type tree
type T Type subtype of T SimpleConstrainedType
name T String The name
description T String Documentation
numParameters T Natural Number of type parameters
var T Natural n T Variance Variance of the n th type parameter
classes T Set T Class All associated classes
subtypes T Set T Type Primary functors of immediate subtypes
supertypes T Set T Type Primary functors of
immediate supertypes
subtypings T Set T TypeConstraint All subtype definitions
involving this type
deepExtent T Set T Object All enumerable objects of this
type and its subtypes
class C Type implements T Type
infinite class C ConstrainedType implements T ConstrainedType
infinite class C SimpleConstrainedType implements T SimpleConstrainedType
The partial order on typ es is subtyping
The users only de ne typ es of the typ e T Type that corresp onds to a typ e explicitely declared in
the program All the other typ es can only b e generated automatically usually during typ echecking
The typ es de ned b elow are not metatyp es as such but are used in metatyp e construction They
are here for completeness of the sp eci cation
type T OpenTypeOrTV subtype of T Object
type T OpenType subtype of T OpenTypeOrTV
primaryFunctor T Type Primary functor
children T List T OpenTypeOrTV Children
type T TypeVariable subtype of T OpenTypeOrTV
type T TypeConstraint
left T OpenTypeOrTV left side of the constraint
right T OpenTypeOrTV right side of the constraint
infinite class C OpenType implements T OpenType
infinite class C TypeVariable implements T TypeVariable
infinite class C TypeConstraint implements T TypeConstraint
The following is the typ e of implementation typ es
type T ImplementationType subtype of T PartiallyOrdered T ImplementationType
name T String The name
description T String Documentation
classes T Set T Class All associated classes
subtypes T Set T ImplementationType Immediate subtypes
supertypes T Set T ImplementationType Immediate supertypes
layout T String host language description
of an object layout
class C ImplementationType implements T ImplementationType
A Class typ es and the metaclasses
type T InfiniteClass covar X subtype of T Object
name T String The name
type T Type Associated type
contains T Object T Boolean Is this an object of this class
itype T ImplementationType Associated implementation type
extends T Set T InfiniteClass T Object Classes that
this one extends
class C InfiniteClass implements T InfiniteClass
type T FiniteClass covar X subtype of T InfiniteClass X
extent T Set X Shallow extent
class C FiniteClass implements T FiniteClass
type T ManualClass covar X subtype of T InfiniteClass X
basicNew X Object creation
class C ManualClass implements T ManualClass
type T Class covar X subtype of T FiniteClass X T ManualClass X
class C Class implements T Class
App endix B
Implementation Notes
In this section design considerations related to various asp ects of implementation of a database
programming language with the typ e system describ ed in this dissertation are presented Most of
these design decisions were conceived discussed and tried out during implementation of the pilot
version of TIGUKAT OODBMS describ ed in OPS and Pet
One of the main goals of the TIGUKAT OODBMS is to provide a uniform ob ject oriented
environment In this environment every entity is an ob ject that p ossesses a typ e that de nes its
interface and an implementation typ e that de nes its memory layout An ob ject is referred to by
its unique object identi er oranOID The only elementary actions are b ehavior applications and
lower level invisible for the user read write op erations on ob ject comp onents attributes
Section B discusses in memory OID structure and the ob ject addressing in general Section B
provides several references on e cientmulti metho d dispatchtechniques Section B describ es the
role implementation typ es play in the system Finally Section B brie y discusses the e ects of
adding p ersistence to the language
B Ob ject identi ers
Since the only elementary action explicitly available in the prop osed language is b ehavior applica
tion e ciency of the language is crucially dep endent on the e ciency of the dispatch mechanism
Since dynamic typ es of ob jects are required for the dispatch to op erate access to the ob ject typ e
information su cient for dispatch purp oses should b e made as e cient as p ossible The most e
cient access to typ e information can b e achieved when it is enco ded directly within an OID Then
in order to dispatch on a particular ob ject this ob ject do es not have to b e accessed at all in fact
it may not b e in the application memory as long as its OID is available
Thus the rst part of an OID is a typeindex Atyp e index do es not enco de the complete ob ject
typ e Rather it denotes a pair of which the rst comp onent is a primary functor of the ob ject s run
time typ e and the second comp onent is the ob ject s implementation typ e Since only the primary
functors make a di erence for the dispatch pro cess the information denoted by the typ e index is
su cient to p erform dispatch The typ e index is in fact an index into a global type table hence
the name Eachentry in the typ e table is a pair denoted by the resp ectivetyp e index In the
current implementation the size of the typ e index eld is bytes which allows for distinct
typ e indices Since only concrete typ es receivetyp e indices this number is likely to b e more than
su cient
The second part of the OID is the ob ject identi er prop er called contents The rst two bits
of this eld identify one of three ob ject varieties For eachvariety the rest of the contents eld is
interpreted di erently In the current implementation the size of the contents eld is bytes
Short atomic ob jects are the ob jects that do not maintain state are immutable andhave small
enough size to t into the contents eld entirely An example of suchanobjectisaninteger number
By enco ding short atomic ob jects in this manner their identity is automatically guaranteed For
example no matter how many times an ob ject app ears in the program all its o ccurrences will have
the same OID and will thus b e indistinguishable from one another An OID of a short atomic ob ject
can b e p erceived as a reference into a constant in nite p o ol of prede ned ob jects The user can
intro duce his own short atomic ob jects by de ning an appropriate implementation typ e for them
Long atomic ob jects are immutable ob jects but with size large enough not to t into the
contents eld For such ob jects the contents eld represents the address on the heap where the
ob ject is lo cated Since long atomic ob jects are immutable reference sharing problems do not arise
Immutable sets and strings are examples of system de ned long atomic ob jects The user can also
intro duce his own long atomic ob jects
Regular ob jects are mutable ob jects For these ob jects the contents eld represents an index
into the global object table Anentry in the ob ject table enco des along with other information the
address of the ob ject on the heap The advantage of this indirect approach is the ability to resize
and move ob jects freely including moving to from p ersistent storage and delete ob jects in a safe
manner The disadvantage is the impact on e ciency made by an additional indirection during each
access Most if not all user de ned ob ject typ es will fall into this category
An implementation typ e can sp ecify the desired interpretation of the contents eld of its ob
ject identi ers by using sp eci ers short atomic long atomic and regular This sp eci cation is
placed in implementation typ es since it is a low level prop erty not essential for interface or structure
sp eci cations
In this section the organization of OIDs was describ ed The next section outlines e cient
dispatch techniques suited for the language in question
B Multiple dispatch
Since the language under consideration features multiple dispatch that requires that dispatch b e done
on the typ es of all arguments rather than on the typ e of the receiver only someofthewell known
e cient dispatchtechniques such as vtables do not apply
Multi metho d dispatch techniques can b e separated into two broad classes cache based and
table based Cache based techniques rely on a sort of a branch prediction mechanism to cache in
the most common case but can take a while to dispatch if a cache miss o ccurs The technique
used in Cecil language is cache based Cha a DCG DGC o ers some improvements in
non re exive case
Table based techniques rely on some sort of a table where all p ossible dispatchvariants are stored
The organization and access to this table is the di erentiating factor b etween the techniques from
this group These techniques are describ ed in CT DAS HSPL HLPS and PHLS
Out of these the technique describ ed in HLPS is the simplest to implementandworks very well
in the presence of typ e system changes Techniques describ ed in HSPL and PHLS are more
e cient O k where k is the b ehavior arity but an additional work is required to adapt them for
a re exive system
In the next section the usage of implementation typ es in low level sp eci cations is describ ed
B Implementation typ es and functions
An implementation typ e is a description of the ob ject s memory layout A sp ecial prede ned im
plementation typ e IT TgObject corresp onds to the implementation of a regular TIGUKAT ob ject
The ob jects of this implementationtyp e have an array of slots that can b e accessed byasetof
primitive functions Ob jects that haveanumb er of sp eci c elds in addition to the array of slots
are represented as instances of implementation subtyp es of IT TgObject
Atomic ob jects that are represented directly bycontents of OIDs are instances of implementation
TgObject The subtyping relationships b etween these typ es is typ es that are not subtyp es of IT
determined by their C implementation For example IT Character and IT Natural are subtyp es
of IT Integer b ecause in C the host language for our implementation anycharacter and any
unsigned numb er can b e treated as an integer On the other hand C integers can not b e treated
as C real numb ers and therefore IT Integer is not an implementation subtyp e of IT Real
Every implementation typ e provides a function to retrieve a full ob ject typ e This is necessary
as the typ e index only gives information necessary for dispatch purp oses which is in general less
then the full typ e e g a list s OID typ e index would tell this is an ob ject of typ e T List X for
some X but it will not b e able to pro duce the value of X
B Adding p ersistence
Persistence has an e ect on b oth global tables and ob ject representation In order to make databases
machine indep endent the following approachwas adopted The representation of an ob ject in the
database on disk and in memory are di erent The translation is provided by a pair of functions
pack and unpack asso ciated with an implementation typ e Thus each implementation typ e may
p otentially haveitsown disk representation Disk OIDs also di er from in memory ones On disk
there are only regular OIDs as b oth short and long atomic OIDs are converted into in line tagged
data Another distinction lies in the size of typ e and ob ject indices Disk structures havemuch
larger index size indices are converted at the moment the ob ject is packed unpacked Thus each
entry of b oth ob ject table and typ e index table contains in addition to other information the long
disk version of the index or if that index has b een created by the program and do es not have
any disk equivalentyet Disk indices are assigned at the time a table entry is packed usually at
transaction commit time
Since schema ob jects liketyp es b ehaviors etc can also b e made p ersistent they have their own
typ e indices and are packed and unpacked by their resp ectivepack unpack routines Dep endencies
between schema ob jects make it necessary to provide a set of rules that determine which ob jects
are to b e made p ersistentwhenaschema ob ject b ecomes p ersistent For example if an ob ject is
made p ersistent its typ e and class b ecome p ersistentaswell These rules are describ ed in detail
in OPS
In this section various implementationandlow level system design issues were brie y discussed
When completed the full implementation of the TIGUKAT OODBMS and its language will most
probably pro duce much more elab orate texts theses or otherwise describing its design
In the current implementation the disk version of an OID is bytes long
App endix C
Mo dule System
This chapter describ es the mo dule system prop osed for the TIGUKAT OODBPL It manages name
spaces in a manner that is orthogonal to the typ e system thus allowing the typ e system to b e free
of name space managementissues
The concept of a module as a unit of name scoping and information hiding was rst intro duced
in Mo dula and its much b etter known o spring Mo dula Wir This concept is extensively used
in the mo dern language design
Languages that make use of this p owerful concept include those of Pascal Mo dula family such
as Ada Ada under the name of packages DBPL SM Ob eron RW Ob eron MW
Mo dula LML and Mo dula Har
Languages from ML language family also make use of the mo dules Mo dules in these languages
however are interface sp eci cations rather than mo dules as such It has b een shown that ML
mo dules can b e used in place of interface typ es in ob ject oriented programming TT This
family of languages includes Standard ML MTH Galileo ACO Amb er Car a and Haskell
HJW
Other languages that utilize mo dules include TM BBdB LOOM BFP Theta LCD
Dylan App Mo dular Smalltalk Hol a TL MMS BETA MMPN under the name of
fragments Java AG and Pizza OW the latter two use the name package
In CL the usage of mo dules in BeCecil is describ ed and their interaction with various ob ject
oriented constructs is investigated
In Jigsaw Bra mo dules are used as one of the central language concepts It is argued that
mo dules b e used instead of classes
Mo dularity and the use of mo dules is also advo cated in TNG
This chapter is organized as follows Section C discusses the problems related to the coupling
of inheritance and name space management in the current ob ject oriented languages Section C
illustrates the concepts of mo dule exp ort and imp ort Inner mo dules are intro duced in Section C
The algorithm for name resolution in the presence of inner mo dules is presented in Section C
Finally Section C brie y discusses issues related to the mo dule p ersistence
C Information hiding and sharing
Traditionally in ob ject oriented languages classes were used as a unit of information sharing and
hiding The b est known example of this approach is C Str with its use of public private
and protected keywords Even though there are no comp elling reasons for coupling inheritance
with name space management this approachwas also adopted in Java AG However due to
well known problems related to this approach Java has a complementary mechanism for dealing
with name space management namely that of packages Packages eliminate the need for cum
b ersome friend constructs that are used in C to overcome the problems related to the coupling
of inheritance and name space management units
In order to illustrate the problems related to such coupling consider the following example Let
T Bank T InvestmentCompany and T InsuranceCompany b e the typ es that de ne interface of their
resp ective real world entities Consider a nancial group that has a bank an investment company
and an insurance company as its comp onents Let FinancialRecords b e a message that can b e sent
to any bank or company to receive nancial records of a given institution Wewould like to make
FinancialRecords available inside the nancial group but not outside of it In the absence of mo d
ules there is no way to accomplish this functionality unless a new wrapp er typ e T FinancialGroup
is de ned However in this case all access to the bank and the investment and insurance company
has to go through the nancial group which means that all public interfaces of the bank investment
and insurance company has to b e duplicated in T FinancialGroup For example if banks and com
panies have a publicly accessible metho d WithdrawFunds that will necessitate the creation of three
metho ds in T FinancialGroup namely WithdrawFundsFromBank WithdrawFundsFromInvestment
and WithdrawFundsFromInsurance This makes the interface de nition unnecessarily complex and
any further interface mo di cation complicated and error prone In the presence of mo dules how
ever a nancial group can b e represented as a module rather than a class That mo dule may exp ort
the bank investment and insurance companies together with their public interfaces but not the
message FinancialRecords
In the prop osed typ e system only the question of message b ehavior hiding is relevant as all
instance variables are hidden and can not b e directly accessed byanytyp e Thus the following
discussion concentrates on the mo dular mechanisms for b ehavior hiding
C Exp ort and imp ort
Every mo dule contains export and import lists A mo dule can b e understo o d a membrane that stops
everything but the names listed in the imp ort list from getting in and it also stops all names except
for those listed in the exp ort lists from getting out
Every entry in the exp ort table is organized as follows It has a quali ed name of the symbol to
exp ort its p ossibly empty alias that will b e used outside the exp orting mo dule and a ag that
indicates whether all names are to b e exp orted The ag only makes sense if this entry exp orts a
mo dule
An entry in the imp ort table also consists of the quali ed name of the imp orted symb ol its
p ossibly empty alias to b e used inside the imp orting mo dule and a ag that indicates whether all
names are to b e imp orted The ag only makes sense if this entry imp orts a mo dule
Example
module M Bank
import all M Finance M FinancialInstitution
import M FinancialInstitution T FinancialInstitution as T Root
export M Bank T Bank M Bank WithdrawFunds
export all M FinancialInstitution
type T Bank subtype of T Root
module M Main
import all M Bank
T Bank bank
bank WithdrawFunds
Here the mo dule M Bank imp orts everything that is exp orted by b oth M FinancialInstitution
and M Finance lo cally renaming T FinancialInstitution imp orted from
M FinancialInstitution as T Root It exp orts the typ e T Bank thebehavior WithdrawFunds
and all symb ols exp orted by M FinancialInstitution The mo dule M Main imp orts all symbols
exp orted by M Bank and can therefore use b oth T Bank and WithdrawFunds
Note that this arrangement allows one to de ne re exp ort of imp orted symb ols p ossibly renaming
them along the way This makes it p ossible to de ne more restrictiveversions of existing mo dules
views For example the following de nes a customer view of a bank
module M CustomerBank
import all M Bank
export M Bank T Bank M Bank WithdrawFunds
Bank and M CustomerBank is that the latter only allows the usage of bank s The di erence b etween M
metho ds but not those of a nancial institution
C Inner mo dules
In order to design hierarchical systems a notion of inner module is intro duced An inner mo dule
is de ned inside another parent mo dule thus the hierarchy of inner mo dules forms a tree The
imp ort list of the inner mo dule contains a sp ecial entry named PARENT Ifthisentry has its all
ag turned on the inner mo dule imp orts all symb ols from its parent mo dule including ones that
are not exp orted Thus an inner mo dule has an access to the internals of its parent mo dule
On the other hand the parent mo dule has access to all symb ols exp orted by the inner mo dule
It do es not have access to the symb ols that the inner mo dule do es not exp ort
There is an additional restriction placed on the inner mo dule exp ort list An inner mo dule can
not exp ort imp orted symb ols that are not explicitly exp orted by its parent mo dule This is done to
disallowbypassing exp ort lists by using inner mo dules
Example
module M Bank
import all M Finance M FinancialInstitution
import M FinancialInstitution T FinancialInstitution as T Root
export M Bank T Bank M Bank WithdrawFunds
export all M FinancialInstitution
type T Bank subtype of T Root
module M Vault
import all PARENT
export T Vault Get Put
type T Vault
Get T Money request T Money received implementation
SecurityStandBy
module M Security
import all PARENT
export SecurityStandBy
Bank only b ehaviors Get and Put of the typ e T Vault can b e used However inside M Vault Inside M
all b ehaviors de ned inside M Bank can b e used including the b ehavior SecurityStandBy exp orted
into the name space of M Bank by the mo dule M Security
The next section gives the algorithm for name search in the presence of inner mo dules
type T Module
Parent T Module Reference to the parent module
NameTable T NameTable Name table
ImportTable T ImportTable Import table
ExportTable T ExportTable Export table
type T NameTable subtype of T Set T NameTableEntry
type T NameTableEntry
Name T String Name being defined
NameDef T NameDef The definition for use by compiler
Module T Module Module reference non NULL
if this is a name of an inner module
type T ImportTable subtype of T Set T IETableEntry
type T ExportTable subtype of T Set T IETableEntry
type T IETableEntry
QName T String Qualified name being imported exported
Alias T String Its alias can be NULL
All T Boolean Are all names imported exported
Only makes sense if this entry
refers to a module
Figure C Mo dule data structures
C Name search
Figures C C C and C de ne the algorithm and the data structures used for name search
in the presence of multiple mo dules The entry p oint of the algorithm is the b ehavior FindSymbol
Figure C For the purp oses of this algorithm it is assumed that every mo dule has a parent
mo dule except for a sp ecial ro ot mo dule that has no imp orts or exp orts This ro ot mo dule is
considered to b e a parent of all mo dules de ned in the global scop e It is also assumed that imp ort
table of every mo dule has an entry marked with a prede ned name PARENT that refers to the
parent of the given mo dule
The algorithm either pro duces the variable de nition along with the mo dule it is lo cated in or
one of two error conditions UNDEFINED or AMBIGUOUS There is a built in ambiguity resolution that
assigns lower priority to symb ols implicitly imp orted from inner mo dules However this is the only
case when one de nition sup ersedes another In all other cases the AMBIGUOUS error o ccurs
Function T Module FindSymbol
Purpose find a symbol in the given module
Input
self the receiver module to locate symbol in
qname qualified name of the symbol to search for
Output
pair of module nameDef where
module module where the found name definition is located
nameDef name definition for use by compiler
Errors
Can throw one of
AMBIGUOUS the name is ambiguous
UNDEFINED the name is undefined
T Module FindSymbol T String qname T NameDef T Module implementation
T Set T Module T String trace
T USet T Number T NameDef T Module results
T NameDef resultND
T Module resultMod
T Number resultPri MAXNUM
T Boolean resultAmbiguous FALSE
FindHere qname TRUE trace results
if results IsEmpty then throw UNDEFINED
Choose the result with the highest priority
If there is more than one this symbol is ambiguous
for each e in results do
T Number priority
T NameDef nameDef
T Module module
priority nameDef module e
if priority resultPri then
resultAmbiguous FALSE
resultPri resultND resultMod priority nameDef module
elseif priority resultPri then
resultAmbiguous TRUE
if resultAmbiguous then
throw AMBIGUOUS
else
return resultND resultMod
Figure C Name search
Function T Module FindHere
Purpose find all symbol definitions available in the given module
Input
self the receiver module to locate symbol in
qname qualified name of the symbol to search for
priority current search priority is the highest
parentSearch a boolean flag that indicates whether
the enclosing module should be searched
trace set of module name pairs already tried
Input Output
results updatable set of results Each result is a triple
that consists of
priority the priority of the successful search
nameDef name definition
module module where the found name definition is located
T Module FindHere T String qname T Number priority T Boolean parentSearch
T Set T Module T String trace
T USet T Number T NameDef T Module results implementation
Attempt to locate the symbol in the name table
and inner modules
for each e in NameTable do
if e Name qname then
results insert priority e NameDef self
elseif e Module NULL then
if e Name IsPrefixOf qname then
T String nameTail qname RemovePrefix e Name
e Module FindExternal nameTail priority trace results
else
e Module FindExternal qname priority trace results
Attempt to locate the symbol among imports
for each e in ImportTable do
if e QName PARENT and not parentSearch then continue
T String name if e Alias NULL then e Alias else e QName
if name IsPrefixOf qname then
T String nameTail qname RemovePrefix name
if e All or nameTail then
T Set T Module T String newTrace self qname
Parent FindHere e QName nameTail priority TRUE newTrace results
Figure C Name search in the given mo dule
Function T Module FindExternal
Purpose find all symbol definitions exported by the given module
Input
self the receiver module to locate symbol in
qname qualified name of the symbol to search for
priority current search priority is the highest
trace set of module name pairs already tried
Input Output
results updatable set of results Each result is a triple
that consists of
priority the priority of the successful search
nameDef name definition
module module where the found name definition is located
T Module FindExternal T String qname T Number priority
T Set T Module T String trace
T USet T Number T NameDef T Module results implementation
Fail if already visited this place
if trace Includes self qname then
return
else
trace Insert self qname
for each e in ExportTable do
T String name if e Alias NULL then e Alias else e QName
if name IsPrefixOf qname then
T String nameTail qname RemovePrefix name
if e All OR nameTail then
FindHere e QName nameTail priority FALSE trace results
Figure C External name search in the given mo dule
Due to the restriction mentioned in the previous section an inner mo dule can not exp ort symbols
from its parent the b ehavior FindHere has an additional argument parentSearch whichissetto
FALSE every time an external search is p erformed This prevents the algorithm from searching the
parent hierarchyofagiven mo dule
The trace is necessary to avoid in nite recursion The reason whysuch a situation can o ccur
is the fact that there are no acyclicity restrictions placed on the imp ort mo dule hierarchy This
signi cantly facilitates the design pro cess The trace is reset in FindHere when the search pro ceeds
to the parent mo dule to reduce the amount of testing required This optimization is valid since only
internal searches are allowed to lo ok in the parent mo dule thus in nite cycles do not o ccur when
the algorithm go es up the parent hierarchy
The data structures depicted in Figure C are related to a single mo dule The name table
contains the set of names de ned in the given mo dule including any inner mo dules present The
imp ort exp ort table represents the set of all imp orts exp orts of the given mo dule Parent refers
to the parentmodule
C Adding p ersistence
Mo dules typ es b ehaviors and all the other schema entities are ob jects and can therefore b e stored
in the database and retrieved from it In order to indicate that a particular mo dule is p ersistent
the PERSISTENT keyword can b e added to its de nition If a mo dule is p ersistent then all typ es
b ehaviors classes functions and inner mo dules de ned in it are also p ersistent Only top level
mo dules can b e declared p ersistent If a mo dule is p ersistent then all mo dules from which it imp orts
should also b e declared p ersistent These restrictions ensure that p ersistent mo dule s dep endencies
p ersist along with the mo dule itself
In this chapter the mo dule system and the algorithm for name resolution have b een describ ed
This mo dule system is orthogonal to the typ e system and therefore do es not a ect typ echecking At
the same time the elab orate imp ort exp ort mechanism along with inner mo dules provides a p owerful
way to deal with information hiding and sharing at the mo dule level The mo dule system is also
capable of mo deling views which is one of the ma jor schema information managementmechanisms
in traditional database management systems