Static Type Inference for Parametric Classes

Abstract

Method inheritance and data abstraction are central features of objectoriented programming that are attained through a hierarchical organization of classes. Recent studies have shown that method inheritance can be supported by an ML style type inference when extended to labeled records. This is based on the observation that a function that selects a eld f of a record can be given a polymorphic type that enables it to be applied to any record which contains a eld f . Several type systems also provide data abstraction through abstract type declarations. However, these two features have not yet been properly integrated in a statically checked polymorphic type system. This paper proposes a static type system that achieves this integration in an ML-like polymorphic language by adding a class construct which allows the programmer to build a hierarchy of classes connected by multiple inheritance declarations. Classes can be parameterized by types allowing generic" de- nitions...

Full text

Page 1

Static Type Inference for Parametric Classes∗
Atsushi OhoriPeter Buneman
Abstract
Method inheritance and data abstraction are central features of object-
oriented programming that are attained through a hierarchical organization of
classes. Recent studies have shown that method inheritance can be supported
by an ML style type inference when extended to labeled records. This is based
on the observation that a function that selects a field f of a record can be given
a polymorphic type that enables it to be applied to any record which contains a
field f. Several type systems also provide data abstraction through abstract type
declarations. However, these two features have not yet been properly integrated
in a statically checked polymorphic type system.
This paper proposes a static type system that achieves this integration in
an ML-like polymorphic language by adding a class construct which allows the
programmer to build a hierarchy of classes connected by multiple inheritance
declarations. Classes can be parameterized by types allowing “generic” defi-
nitions. The type correctness of class declarations is statically checked, and a
principal scheme is inferred for any type correct program containing methods
and objects defined in classes. Moreover, the type system can be extended to
include the structures and operations needed for database programming and
therefore can serve as a basis of an object-oriented database programming lan-
guage.
1Introduction
Code sharing is a term that implies the ability to write one piece of code that can
be applied to different kinds of data. What this means in practice depends on what
we mean by “kinds of data”. In object-oriented languages [GR83] each data element
(object) belongs to a unique member of a class hierarchy. The code that is applicable
to that object is not only the code that is defined in its own class but also the
one defined in its super-classes. As an example, we can define a class person with a
method increment age that increments a person’s age by 1. We may define a subclass,
∗Published in a book “Theoretical Aspects of Object-Oriented Programming Types,
Semantics and Language Design”, C. Gunter and J. Mitchell, editors, pages 121 – 148,
MIT Press, 1994.
This is an extended version of the paper appeared in Proc. ACM OOPSLA Conference.
445–456. New Orleans, LA., 1989.
This research was supported in part by grants NSF IRI86-10617, ARO DAA6-29-84-k-0061 and
ONR NOOO-14-88-K-0634.
Authors’ current address: Atsushi Ohori: Oki Electric Industry, Kansai Laboratory, Crystal Tower,
1-2-27 Shiromi, Chuo-ku, Osaka 540, JAPAN. Peter Buneman: Department of Computer and Infor-
mation Science, University of Pennsylvania, Philadelphia, PA 19104-6389.
Pages
1

Page 2

employee, of person and expect that the same method, increment age, can be applied
to instances of the class employee.
In contrast, languages such as Ada [IBH+79], CLU [LAB+81], Standard ML
[HMT88] and Miranda [Tur85] — to name a few — provide a generic or polymorphic
type system that allows code to be refined by instantiating type variables. Moreover,
in the type system of ML, a most general polymorphic type-scheme may be inferred
for an (untyped) function and the correctness of the application of that function is
checked by finding a suitable instantiation of the type variables. For example, in ML,
one may define a polymorphic function reverse that reverses a list. From a definition
of reverse that contains no mention of types, the ML type system is able to infer that
list(t) → list(t) is a most general polymorphic type-scheme of reverse where t is a
type variable. One may subsequently apply this function to a list of arbitrary type,
i.e. a value of any type of the form list(τ). Through this polymorphic type inference
mechanism, ML achieves much of the flexibility of programming without the need
to express type information, as in dynamically typed languages, while maintaining
most of the advantages — for program correctness and efficiency — of a static type
system. A drawback to ML is that it does not combine data abstraction with inher-
itance in the same sense that object-oriented languages do this. While ML provides
data abstraction through abstract data type declarations, it does not allow these to
be organized into a class hierarchy.
The purpose of this paper is to develop a static type system that supports both
forms of code sharing by combining ML polymorphism and explicit class definitions.
In our type system a programmer can define a hierarchy of classes. A class can be
parametric and can contain multiple inheritance declarations. The type correctness
of such a class definition (including the type consistency of all inherited methods)
is statically checked by the type system. Moreover, apart from the type assertions
needed in the definition of a class, the type system has a static type inference similar
to that available in ML.
We develop such a type system by exploiting a form of type inference for labeled
records and labeled disjoint unions originally suggested by Wand [Wan87]. Labeled
records and labeled disjoint unions are the structures that one naturally uses to im-
plement a class hierarchy. For example, to implement a subclass in object-oriented
languages one usually adds instance variables to those of the parent class; but one can
equally well think of this as adding fields to a record type that implements the parent
class. We combine a type inference system for these structures with explicit type dec-
larations that represent classes. The main technical contribution is to demonstrate
that such a combination is possible. We show that the resulting type system is sound
with respect to the underlying type system and that it has a type inference algorithm.
These results can be used to develop a programming language that integrates central
features of object-oriented programming and those of statically typed polymorphic
languages. Moreover, it is also possible to extend the type system to incorporate a
number of structures and operations for database programming. The extended type
system can serve as a basis for database programming languages, where databases are
represented as typed data structures and queries and other database operations are
cleanly represented as statically typed polymorphic functions. Parametric classes and
polymorphism capture various aspects of object-oriented databases. Based on these
results a prototype programming language embodying the type system described in
2

Page 3

this paper (with the exception of class parameterization) has been implemented at
University of Pennsylvania. The “core” of the language, i.e. the language without class
construct, was described in [OBBT89]. A more detailed description of the language
can be found in [BO90].
Wand [Wan87] observed that method inheritance can be supported in an ML-
like strongly typed language by extending ML’s type inference mechanism to la-
beled records and labeled disjoint unions.
to record types and inheritance is realized by polymorphic typing of functions on
records. For example, if we represent the classes person and employee by the record
types [Name : string,Age : int] and [Name : string,Age : int,Salary : int]
then the requirement that the method increment age defined on the class person
should be inherited by employee simply means that the type of the function in-
crement age should be a polymorphic type whose instances include not only the
type [Name : string,Age : int] → [Name : string,Age : int] but also the type
[Name : string,Age : int,Salary : int] → [Name : string,Age : int,Salary : int].
Wand’s system, however, does not share ML’s feature of existence of principal
typing schemes (see [OB88, Wan88] for an analysis of this issue.) Based on Wand’s
general observation, [OB88] extended the notion of principal type-schemes to include
conditions on type variables. (See also [Sta88, JM88, Rem89, Wan89] for related stud-
ies.) This extension allows ML polymorphism to be extended to standard operations
on records and variants and also to various database operations such as join and
projection. (See also [Wan89, CM89, HP91, Rem91] for proposals for other opera-
tions on records.) For example, the function increment age can be implemented by
the following code:
In this paradigm, classes correspond
fun increment age(p) = modify(p,Age,p.Age + 1)
where e.l selects the l field from the record e, and modify(p,l,e) returns the new
record that is same as p except that its l field is changed to e. For this function, the
following principal conditional type-scheme is inferred:
[(t)Age : int] → [(t)Age : int]
The notation [(t)l1: τ1,...,ln: τn] represents a conditional type variable t, for which
substitutions are restricted to those θ such that θ(t) is a record type containing the
fields li : θ(τi),1 ≤ i ≤ n.
string,Age : int,Salary : int] satisfy the condition, [Name : string,Age : int] →
[Name : string,Age : int] and [Name : string,Age : int,Salary : int] → [Name :
string,Age : int,Salary : int] are both instances of the above conditional type-
scheme. By this mechanism the function increment age can be safely applied not
only to person objects but also to employee objects.
The type inference method suggested by this example shows an integration of
method inheritance and a static type system with ML polymorphism. This approach
is not subject to the phenomenon of “loss of type information” associated with type
systems based on the subsumption rule [Car88] – the problem observed by Cardelli
and Wegner [CW85] (see [BTBO89] for a discussion on this problem). However this
approach relies on the structure of record types of objects: inheritance is derived
from the polymorphic nature of field selection. We would like to borrow from object-
oriented languages the idea that the programmer can control the sharing of methods
Since both [Name : string,Age : int] and [Name :
3

Page 4

through an explicitly defined hierarchy of classes and that objects are manipulated
only through methods defined in these classes, achieving data abstraction.
Galileo [ACO85] integrates inheritance and class hierarchies in a static type system
by combining the subtype relation in [Car88] and abstract type declarations. Galileo,
however, does not integrate polymorphism or type inference. [JM88] suggests the
possibility of using their type inference method to extend ML’s abstract data types to
support inheritance. Here we provide a formal proposal that achieves the integration
of ML style parametric abstract data types and multiple inheritance by extending
the type inference method presented in [OB88]. The class declarations we describe
can be regarded as a generalization of ML’s abstract data types, but there seems to
be no immediate connection with the notion of abstract types as existential types in
[MP85].
As an example, the class person can be implemented by the following class defini-
tion:
class person = [Name : string,Age : int] with
fun make person(n,a) = [Name = n,Age = a]
: (string ∗ int) → person;
fun name(p) = p.Name : sub → string;
fun age(p) = p.Age : sub → int;
fun increment age(p) = modify(p,Age,p.Age + 1)
: sub → sub;
end
Outside of this definition, the actual structure of objects of the type person is hidden
and person objects can only be manipulated through the explicitly defined set of
interface functions (methods). This is enforced by treating classes as if they were
base types and the methods as the primitive operations associated with them.
As in Miranda’s abstract data types, we require the programmer to specify the
type (type-scheme) of each method. The keyword sub in the type specifications of
methods is a special type variable representing all possible subclasses of the class
being defined. It is to be regarded as an assertion by the programmer (which may
later prove to be inconsistent with a subclass definition) that a method can be applied
to values of any subclass. For example, we may define a subclass
class employee = [Name : string,Age : int,Sal : int]
isa person with
fun make employee(n,a) =
[Name = n,Age = a,Sal = 0]
: (string ∗ int) → employee;
fun add salary(e,s) = modify(e,Sal,e.Sal + s)
: (sub ∗ int) → sub;
fun salary(e) = e.Sal : sub → int
end
which inherits the methods name, age and increment age, but not make person from
the class person because there is no sub in the type specification of make person.
For reasons that will emerge later we have given the complete record type required
4

Page 5

to implement employee, not just the additional fields we need to add to the imple-
mentation of person. It is possible that for simple record extensions such as these we
could invent a syntactic shorthand that is more in line with object-oriented languages.
Continuing in the same fashion, we may define classes
class student =
[Name : string,Age : int,Grade : real]
isa person with
...
end
class researchFellow =
[Name : string,Age : int,Grade : real,Sal : int]
isa {employee,student} with
...
end
The second of these illustrates the use of multiple inheritance.
The type system we are proposing can statically check the type correctness of these
class definitions containing multiple inheritance declarations.
system always infers a principal conditional type-scheme for expressions containing
methods defined in classes. For example, for the following function
Moreover, the type
fun raise salary(p) = add salary(p,div(salary(p),10))
which raises the salary of an object by approximately 10%, the type system infers the
following principal conditional type-scheme:
(t < employee) → (t < employee)
where (t < employee) is a conditional type variable whose instances are restricted to
subclasses of employee. This function can be applied to objects of any subclass of
employee and the type correctness of such applications is statically checked.
To demonstrate the use of type parameters, consider how a class for lists might
be constructed. We start from a class which defines a “skeletal” structure for lists.
class pre list = (rec t.?Empty : unit,List : [Tail : t]?)
with
nil = ?Empty = ()? : sub;
fun tl(x) = case x of
?Empty = y? ⇒ ...error...;
?List = z? ⇒ z.Tail;
end : sub → sub
fun null(x) = case x of
?Empty = y? ⇒ true;
?List = z? ⇒ false;
end : sub → bool;
end
5