ECOOP '95 - Object-Oriented Programming: 9th European Conference, Aarhus, Denmark, August 7 - 11, 1995. Proceedings (Lecture Notes in Computer Science) 9783540601609, 3540601600

Citation preview

Lecture Notes in Computer Science Edited by G . Coos. J . Hartmanis and J. van Leeuwen Advisory Board: W. Brauer

I>. Cries

J . Stoer

952

Springer Berlin Heidelberg New York Barcelona Budapest Hong Kong London Milan Paris Tokyo

Walter Olthoff (Ed.)

ECOOP '95Object-Oriented Programming 9th European Conference Aarhus, Denmark, August 7-11, 1995 Proceedings

Springer

Series Editors Gerhard Goos UniversWit Karlsruhe Vincenz-Priessnitz-StraBe 3, D-76128 Karlsruhe, Germany Juris Hartmanis Department of Computer Science, Cornell University 4130 Upson Hall, Ithaca, NY 14853, USA Jan van Leeuwen Department of Computer Science, Utrecht University Padualaan 14, 3584 CH Utrecht, The Netherlands Volume Editor Walter Olthoff Deutsches Forschungszentrum fUr Kiinstliche Intelligenz Postfach 20 80, D-67608 Kaiserslautern, Germany Cataloging-in-Publication Data applied for

Die Deutsche Bibliothek - CIP-Einheitsaufnahme Object oriented programming: 9th European conference, proceedings I ECOOP '95, Arhus, Denmark, August 7 - 11, 1995. Walter Olthoff (ed.). - Berlin; Heidelberg; New York: Springer, 1995 (Lecture notes in computer science; Vol. 952) ISBN 3-540-60160-0 (Berlin ... )

NE: Olthoff, Walter [Hrsg.J; ECOOP ; GT

CR Subject Classification (1991): D.I-3, H.2, J.l ISBN 3-540-60160-0 Springer-Verlag Berlin Heidelberg New York This work is subject to copyright. All rights are reserved, whether the whole or part of the material is concerned. specifically the rights of translation, reprinting, re-use of illustrations, recitation, broadcasting, reproduction on microfilms or in any other way, and storage in data banks. Duplication of this publication or parts thereof is permitted only under the provisions of the German Copyright Law of September 9, 1965, in its current version, and permission for use must always be obtained from Springer -Verlag. Violations are liable for prosecution under the German Copyright Law. © Springer-Verlag Berlin Heidelberg 1995 Printed in Germany

Typeselting: Camera-ready by author SPIN 10486478 06/3142 - 543 2 I 0

Printed on acid-free paper

Preface For the ninth time now, the European Conference on Object-Oriented Programming provides a mid-summer gathering place for researchers, practitioners, students and newcomers in the field of object technology. Despite fierce competition from an increasing number of attractive conferences on object-related topics, ECOOP has successfully positioned itself as the premier European object technology conference. One reason is without doubt the composition of the conference week and the nature of its events. Running in parallel on the first two days, a comprehensive tutorial program and a very selective workshop program are offered to attendees. This is followed by a three-day technical program organized in a single track providing a highly communicative atmosphere of scientific exchange and learning. Overlapping with these events are a two-day industrial exhibition and a two-day opportunity for non-industrial system developers to demonstrate their software. Thus, ECOOP is not just a conference on programming but an event touching on the full spectrum of object technology. This volume constitutes the proceedings of the Ninth European Conference on Object-Oriented Programming, ECOOP, held in Aarhus, Denmark, August 7-11, 1995. Previous ECOOP conferences were held in Paris (France), Oslo (Norway), Nottingham (England), Ottawa (Canada, jointly with OOPSLA) , Geneva (Switzerland), Utrecht (the Netherlands) , Kaiserslautern (Germany), and Bologna (Italy). Object technology continues to increase its impact on the corporate world. Leading companies devote more and more resources to object-oriented develop ment of new software or the gradual adaptation of legacy systems to the object perspective. This results in constant demand for excellent research results, improved development environment concepts and more sophisticated methods for analysis and design. Driven by these forces, ECOOP both benefits and suffers from the fluctuation of economic parameters. This year, 90 papers were submitted from 19 countries around the world, with significant North American representation. The latter fact probably reflects a kind of load sharing ECOOP has established with the OOPSLA conference series. Jointly they provide a biannual forum for publication of original high-quality object technology research. The selection of papers was carried out during a two-day program committee meeting in Kaiserslautern. Papers were judged according to their originality, relevance and presentation quality, and acceptance was based purely on their own merits, independently of other submissions. The 18 selected papers are of remarkable quality, and range in topic from more theoretical areas like type theory and verification to implementation aspects of programming paradigms, including concurrency, distribution, reflection, specification and interfaces. Although the presentation of the selected papers will constitute the kernel of the technical program, the keynote address and the two invited talks will address essential experiences, visions and research overviews related to the theory and practice of object technology. A paper related to each of the invited talks is included in this volume.

VI

ECOOP95 is the result of considerable effort on the part of a number of people. It has been a pleasure to work together with the members of the program committee and the referees, who each devoted much time in reviewing and discussing the submitted papers. The collaboration with Ole Madsen (Conference Chair) and Jorgen Knudsen (Organizing Chair) was excellent and very effective, despite the hinderances of differing time zones. Thanks must also go t o those responsible for the organization of the various ECOOP events: Birger MollerPedersen, Eric Jul, Boris Magnusson, Kurt Normark, Elmer Sandvad, and to those who helped in the local organization in Aarhus and Kaiserslautern: Susanne Brondberg, Janne Damgaard, Marianne Iversen and Cornelia Wanders. Finally, ECOOP95 has greatly benefitted from the support of sponsoring organizations whose support and cooperation are gratefully acknowledged. DFKI GmbH graciously provided me with the time and support necessary to serve as Program Chair. Ultimately, the success of ECOOP95 will be determined by the number of attendees who leave Aarhus with the memory of time well spent. Knowing details of the prepared events I am confident that we will receive a very good rating on this scale. Enjoy the conference and this book!

April 1995

Walter Olthoff Program Chair ECOOP’95

Organization ECOOP’95 is organized by the Department of Computer Science, University of Aarhus and AITO (Association Internationale pour les Technologies Objets) in cooperation with ACM/SIGPLAN.

Executive Committee Conference Chair: Program Chair: Organizing Chair: Tutorials: Workshops: Panels: Exhibition: Demonstrations:

Ole Lehrmann Madsen (Aarhus University, DK) Walter Olthoff (DFKI GmbH, Germany) Jorgen Lindskov Knudsen (Aarhus University, DK) Birger Mdler-Pedersen (Norwegian Computing Center, Norway) Eric Jul (University of Kopenhagen, Denmark) Boris Magnusson (Lund University, Sweden) Elmer Sandvad (Aarhus University, Denmark) Kurt Nmmark (Aalborg University, Denmark)

Program Committee Mehmet Aksit Pierre America Jean Bezivin Pierre Cointe BjGrn Freeman-Benson Yutaka Ishikawa Eric Jul Gerti Kappel Mary Loomis Boris Magnusson Paola Mello Jos6 Meseguer Bertrand Meyer Oscar Nierstrasz Walter Olthoff Andreas Paepcke Jens Palsberg Remo Pareschi Markku Sakkinen Alan Snyder Dave Thomas Mario Tokoro Peter Wegner Roberto Zicari

University of Twente, Netherlands Philips, Netherlands Universit6 de Nantes, France Ecoles des Mines de Nantes, France Carleton University, Canada RWCP, Japan University of Kopenhagen, Denmark University of Linz, Austria Hewlett-Packard, USA Lund University, Sweden UniversitS di Bologna, Italy SRI International, USA ISE, USA/France University of Bern, Switzerland DFKI GmbH, Germany Stanford University, USA Aarhus University, Denmark Rank Xerox, France University of Jyvaskyla, Finland SunSoft, Inc., USA Object Technology International, Canada Keio University / Sony CSL, Japan Brown University, USA Johann-Wolfgang-von-Goethe-Universitat,D

Vlll

Referees Birger Andersen Peter Bichler Uwe Borghoff Philippe Brkche Kim Bruce Frank Buddrus Michele Bugliesi Luca Cardelli Giuseppe Castagna Anna Ciampolini Antonio Corradi Enrico Denti Christophe Dony Gregor Engels Kathleen Fischer Steve Freeman Yasuhisa Fujinami Natalie Glance Roberto Gorrieri Kari Grano Jorgen Greve Karl Guggisberg Gore1 Hedin Yasuaki Honda

Juhani Iivari Christian Jensen Niels Christian Juul Gregor Kiczales Kai Koskimies Evelina Lamma John Lamping Sven-Eric Lautemann Ulrike Lechner Thomas Ledoux Letizia Leonardi Patrick Lincoln Frank van der Linden Markus Lumpe Munenori Maeda Jacques Malenfant Francesco Marcelloni Narciso Marti-Oliet Satoshi Matsuoka Michael Moustgaard The0 Dirk Meijler Martin Miiller Philippe Mulet Piero Mussio

Jorg Nolte Jens Cornelius Olsen Andrea Omicini Jukka Paakki Lars Jarnbo Pedersen Wolfgang Pree Sigi Reich Philippe Reitz Werner Retschitzegger Tamar Richner Fred Rivard Jorma Sajaniemi Ichiroh Satoh Jean-Guy Schneider Michael Schwartzbach Cesare Stefanelli Antero Taivalsaari Bedir Tekinerdogan Patrick Varone Juha Vihavainen Mario Wolczko Franco Zambonelli Eddy Zondag

Sponsoring Inst it utions

ACM/SIGPLAN: Association of Computing Machinery - Special Interest Group in Programming Languages AITO: Association Internationale pour les Technologies Objets CINCOM Systems, Denmark DAIMI: Department of Computer Science, University of Aarhus, Denmark Den Danske Bank, Denmark DEVISE: Centre for Experimental System Development, Univ. of Aarhus, DK Faculty of Science, University of Aarhus, Denmark Sun Division, ICL Data A/S, Denmark

Contents Keynote Address (Abstract) Experiences on The Road to Object Utopia ................................ Dave Thomas (Object Technology International)

.l

The Cartesian Product Algorithm ......................................... Ole Agesen (Stanford University)

.2

PolyTOIL: A Type-Safe Polymorphic Object-Oriented Language Kim B. Bruce (Williams College, Williamstown) Robert van Gent (Stanford University) Angela Schuett (University of California at Berkeley)

.......... .27

Object Imaging ........................................................... Satish R. Thatte' (Clarkson University, Potsdam)

52

Programming Languages Optimization of Object-Oriented Programs Using Static Class Hierarchy Analysis ................................................. Jeffrey Dean, David Grove, Craig Chambers (University of Washington) Objects with Multiple Most Specific Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Elisa Bertino (Universatd di Milano) Giovanna Guerrini (Universitd di Genova) A Marriage of Class- and Object-Based Inheritance Without Unwanted Children ...................................................... Patrick Steyaert, Wolfgang De Meuter (Free University of Brussels)

.77

102

127

Invited Talk On Subtyping and Matching ............................................. Mart& Abadi, Luca Cardelli (Digital Systems Research Center)

145

X

Reflective Programming / Verification Using Metaobject Protocols to Implement Atomic Data Types . . . . . . . . . . . . 168 R.J. Stroud, 2. Wu (University of Newcastle upon Tyne) Meta-level Programming with CodA ..................................... 190 Jeff McAffer (University of Tokyo and Object Technology International) An Object-Oriented Framework for the Formal Verification of Processors ............................................................ Laurent Arditi, He'lsne Collavizza (Universite' de Nice)

.215

Implementation Incremental Mature Garbage Collection Using the Train Algorithm ......................................................... Jacob Seligmann, Steflen Grarup (Aarhus University) Message Dispatch on Pipelined Processors ............................... Karel Driesen, Urs Holzle (University of California, Santa Barbara) Jan Vitek (Universite' de Genehe)

235 .253

Do Object-Oriented Languages Need Special Hardware Support? . . . . . . . . .283 Urs Holzle (University of California, Santa Barbara) David Ungar (Sun Microsystems Laboratories)

Invited Talk Programming as an Experience: The Inspiration for Self . . . . . . . . . . . . . . . . ..303 Randall B. Smith, David Ungar (Sun Microsystems Laboratories)

Concurrency

/

Specification

Time and Asynchrony in Interactions among Distributed Real-Time Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .331 Ichiro Satoh (Keio University) Mario Tokoro (Keio University and Sony Computer Science Laboratory) Object Protocols as Functional Parsers .................................. Gert Florajn (Utrecht University) Interface-Based Protocol Specification of Open Systems using PSL ............................................................... Doug Lea (SUNY at Oswego) Jos Marlowe (Sun Microsystems Laboratories)

.351

374

XI

Distribution

/

Interfaces

Experience Using Design Patterns to Evolve Communication Software Across Diverse 0 s Platforms ............................................ Doug Schmidt (Washington Unauersaty) Paul Stephenson (Ericsson Inc.) Sharing Properties in a Uniform Object Space ........................... Heiko KaepEing, Uwe Kruger (University of Karlsruhe)

.399

.424

ChyPro: A Hypermedia Programming Environment for Smalltalk-80 . . . . . .449 Maurice Amsellem (Universite' de Paris)

Author Index .......................................................

471

Keynote Address

Experiences on The Road to Object Utopia Dave Thomas (Object Technology International)

The talk will present lessons from nearly a decade of experience in making object technologies real in the industrial world. It is also the story of ten years of opportunities for object-oriented research and development activities. From this starting point a critical look is given at where we have been and where we are going to with object technology research and practice. Dave Thomas has 30 years of experience in the computer industry as an architect, project manager and director. Dave holds an adjunct research professorship a t Carleton University where he previously held the position of Director of Object-Oriented Research Group. During the last 12 years Dave has specealized in the design and implementation of object-oriented systems. Projects have included the successful development and implementation of systems for client-server, embedded systems, manufacturing, networking systems, electronic publishing, integmted circuit testing, defence and instrumentation. Dave is widely published in object-oriented litemture. He has served on the program committees for the OOPSLA a n d ECOOP conferences for the past 8 years. Dave is founder and CEO of Object Technology International, Inc. (OTI). O T I is an advanced software technology company and a world leader in objectoriented technology. The company’s primary business is joint product development and technology licensing. OTI’s ENVY portfolio of software components, tools, technology and processes enable OTI alliance partners to develop and deploy innovative tools and products. Over the last 10 years, OTI’s products a n d technology have been key in the commercialization of the Smalltalk language.

W. Olthoff (Ed.): ECOOP ’95, LNCS 952, p. 1, 1995. 0 Spnnger-Verlag Berlin Heidelberg 1995

The Cartesian Product Algorithm Simple and Precise Type Inference Of Parametric Polymorphism Ole Agesen Computer Science Department, Stanford University Stanford, CA 94305 agesen @cs.stanford.edu Abstract. Concrete types and abstract types are different and serve different purposes. Concrete types, the focus of this paper, are essential to support compilation, application delivery, and debugging in object-oriented environments. Concrete types should not be obtained from explicit type declarations because their presence limits polymorphism unacceptably. This leaves us with type inference. Unfortunately, while polymorphism demands the use of type inference, it has also been the hardest challenge for type inference. We review previous type inference algorithms that analyze code with parametric polymorphism and then present a new one: the Cartesian product algorithm. It improves precision and efficiency over previous algorithms and deals directly with inheritance, rather than relying on a preprocessor to expand it away. Last, but not least, it is conceptually simple. The Cartesian product algorithm has been used in the Self system since late 1993. We present measurements to document its performance and compare it against several previous algorithms. Keywords: concrete types, abstract types, type inference, polymorphism, inheritance, Self.

1 Introduction 1.1 Concrete versus Abstract Types Concrete types (a.k.a. implementation types or representation types) are sets of classes. For example, an expression that returns instances of class L i s t St a c k has concrete type { L i s t s t a c k } , and an expression that returns instances of either class ArrayStack or L i s t s t a c k has concrete type {Arraystack, L iststa c k} . Concrete types provide detailed information since they distinguish even different implementations of the same abstract data type. In contrast, abstract types (a.k.a. interface types or principal types) capture abstract properties of objects. They may not distinguish between different implementations of the same abstract data type: both list-based and array-based stacks may have an abstract type like [push: elmType+void; pop:void-+elmTypel . Probably the best known inference algorithm for abstract types is Milner's [16]. Concrete and abstract types are extremes in a spectrum of type systems. Classtypes, as found in BETA, C++, and Eiffel, are neither fully abstract (it is impossible to express the type of any object that has a push and a pop operation), nor fully concrete (declaring an object with class type Stack, does not reveal the specific subclass of which it is an instance).

W. Olthoff (Ed.): ECOOP '95, LNCS 952, pp. 2-26, 1995. 0Springer-Verlag Berlin Heidelberg 1995

3

Concrete types are the focus of this paper. Previous publications have argued that they directly support solutions to several important problems in object-oriented programming environments: Compilation. Concrete types support important optimizations such as elimination of dynamic dispatch and method inlining [17,21]. Extraction. Concrete types support delivery of compact applications by enabling an extractor to sift through an image of objects, selecting those that are essential to run a given application [4]. Browsing/debugging. Concrete types help a programmer understand programs by allowing a browser to track control flow (and thereby data flow) through dynamically dispatched message sends [3]. The need for concrete type information may be greater in object-oriented environments than in “conventional” (C-like) environments: object-oriented programs consist of many small methods (hence, inlining is important); emphasis on code reuse yields large and general class libraries (hence, extraction is important); and understanding object-oriented programs is harder because control- and data-flow are coupled (hence, browsers should assist). Even statically-typed languages like C++ can use concrete type information since the above three problems are not supported well by class types. For instance, knowing that an object is an instance of class Stack,is generally not sufficient to inline operations on it (the program may contain several subclasses of Stack and from the static type declaration we cannot tell which specific one occurs - but concrete type inference may tell) [ 131.

1.2 Polymorphism Polymorphism, the ability of a piece of code to work on several kinds of objects, is a central part of object-oriented programming. Polymorphism is desirable because it enables more code reuse. We distinguish between two kinds. Parametric polymorphism is the ability of routines to be invoked on arguments of several types. A length function that works on both singly-linked and doubly-linked lists exhibits parametric polymorphism. Data polymorphism is the ability to store objects of different types in a variable or slot’. “Link” objects forming a heterogeneous list of integers, floats, and strings, exhibit data polymorphism because their “contents” slots contain objects of several types. Explicit (programmer-inserted)concrete type declarations are undesirable because they limit polymorphism and code reuse. For example, adding the type declaration { Int, Float) to the formal arguments of a m a x routine makes it less reusable, because it can no longer be used to find the larger of two strings. Given that explicit concrete type declarations are undesirable, the considerable interest in inference algorithms is not surprising [3, 11, 17, 18, 19,20,25].Ironically, while the desire to maximize polymor-

I . Slots in Self provide the functionality of instance variables, parents, formal arguments, and

local variables.

4

phism demands type inference, polymorphism is also the hardest challenge for inference algorithms. To illustrate this, we applied a simple inference algorithm (“the basic algorithm,” see Section 2.2) to the Self expression 3 0 factorial,where the fact o r i a l method for an integer receiver is defined by factorial = ( self a ifTrue: [ s e l f ] False: [ a ] ) .

Let aslotdenote the slot a , and a,,d the expression which reads the slot a in the block [a]. Let typeT be the type of a slot or an expression in a template T. Assume we have two max :-templates, S and T, for which:

{z}

typeS(se1f) = types(a,lot) = and typeT(self) = typeT(a,lot) = { f l o a t ] .

What should type(a,,d) be? A simple approach is to assume that a,,d may access aslotin any max :-template., i.e., type(aEd) = types(a,lot) u typv(a,lot) = {int, f l o a t }. Unfortunately, precise types cannot be inferred under this pessimistic assumption. To do better, analysis must closely parallel execution. Invoking m a x : with an integer argument creates an activation record in which a is bound to an integer. When the block [ a 3 is evaluated, the result is a closure whose lexical pointer is set to this activation record. Later, when the closure is invoked, the lexical pointer is used to retrieve the value of a. To improve type inference precision, this two-phase evaluation of blocks must be simulated. Templates correspond to activation records, so we create type-inference-time closures that have a lexical pointer referring to a template, e.g., ( [ a I , S). When the closure is analyzed, the lexical pointer is used to find, e.g., that type(a,,& = types(a,lot) = Now it is possible to infer precise types. The above approach is not specific to Self- or Smalltalk style blocks; e.g., it also applies to Pascal’s nested procedures, Scheme’s closures and Beta’s nested patterns. Closures and Termination. The precise way to analyze blocks may result in nontermination of type inference, when using an adaptive type inference algorithm such as the iterative algorithm or CPA. The reason is that new templates result in creation of new block closures which in turn may result in creation of new templates. The simplest example is a method which invokes itself with a closure of its own:

{z}.

foo: b l k = ( foo: [ b l k value] ) .

More complicated cases involve indirect recursion. Plevyak and Chien discuss this in [20]. The general solution is to break the infinite computation by creating a cycle in the constraint graph. Closures and efficiency. Efficiency of type inference is highly sensitive to the number of closures created. This is due to “self-amplification”: more closures result in more templates which in turn result in more closures etc. Consequently, we should create as few closures as possible. However, as outlined above, the simple approach of having only a single closure per block is too imprecise. One way to reduce the number of closures, without impairing precision, is to “fuse” closures when this is safe. Assume we have four templates for max : , S and T from above, and U and V with

typ eu ( s el f ) = {int}, ty p e v ( s e l f ) = { f l o a t } ,

typeu(aSlot)= { f l o a t ] and typev(aSlot)={EX}.

Even though we have four max:-templates, two closures for each of the blocks [ s e 1f J and [ a ] suffice. The reason is that the types in the [a I block only depends

26

on the type of aslot.This type is the same in S and V, and it is the same in T and U. Creating two closures ( [aI , { S,V}) and ( [a1 , { T,U}) saves analysis effort because it, in turn, will necessitate fewer i f T r u e :Fa1se :-templates. This optimization complicates matters because closures at analysis time, unlike at execution time, now may have several scopes. For Self, we found the performance gain high enough to be worth the added complexity. Reaching definitions. Assignments are non-destructive in type inference. They do not erase the old type of a slot they assign to, so clone families keep accumulating in the types for assignable slots. This conservatism is necessary in general, but sometimes we can do better. Four increasingly powerful approaches are: do nothing, eliminate dead initializers, use static single assignment (SSA) form, and propagate definitions through the call graph as it is constructed during type inference. In the Self implementation we have tested the first three approaches, but only for local slots. (“Instance slots” are harder to deal with because they may both be aliased and represent multiple locations). We found that the simple elimination of unused initializers pays off significantly, and that SSA is only slightly better. We suspect that this is because most local slots are initialized to n i 1,but immediately assigned to something more useful; simply getting rid of 3from the type of the slot achieves most of what can be obtained. Coupled arguments. Assume that type(x) = { int,float} and type(y) = {X, float}. The send x+y connects to four templates, one for each of the four tuples in the Cartesian product of the types of x and y.In contrast, the send x+x should only connect to two templates: and (float,f l o a t ) , since if the receiver is an integer, so is the argument (the form of the send enforces that the receiver and argument is the same object). The receiver and argument are coupled. Coupling need not involve the exact same object, just objects that are (somehow) bound to be in the same clone family. In general, determining if two arguments are coupled is not computable, but safe approximations are possible. We implemented a simple approximation, but it had only a marginal effect on analysis of typical Self programs, possibly because we need more powerful detection, but more likely just because coupling is rare. Grouping. The Self type inferencer analyzes an image of objects, not programmerwritten source code. Consequently, it may encounter many “similar” objects in the image (e.g., 10,000 point objects that are part of a graph on the display). Inferring types for each object individually is computationally infeasible. To overcome this problem, we group objects according to structural similarity before inferring types [4]. Grouping may cost precision, but speeds up inference since all members of a group can be analyzed “in parallel.”

(z, x)

~~

PolyTOIL: A Type-Safe Polymorphic Object-Oriented Language* Extended Abstract Kim B. Bruce, Angela Schuett-, and Robert van GentWilliams College, Williamstown,

MA 01267

Abstract. PolyTOIL is a new staticdy-typed polymorphic object-oriented programming language which is provably type-safe. By separating the definitions of subtyping and inheritance, providing a name for the type of se& and carefully defining the type-checking rules, we have obtained a language which is very expressive while supporting modular typechecking of classes. The matching relation on types, which is related to F-bounded quantification, is used both in stating type-checking rules and expressing the bounds on type parameters for polymorphism. The design of PolyTOIL is baaed on a careful formal definition of type-checking rdes and semantics. A proof of type safety is obtained with the aid of a subject reduction theorem. Categories: Type systems, design and semantics of object-oriented languages.

1

Introduction

Because of the complexity of object-oriented languages, it has proven t o be very difficult to design typesafe statically-typed object-oriented languages which are also very expressive. At one extreme we have statically-typed languages like C++ [ES90] and Object Pascal [Tes85]which come close t o type safety, but whose rigid and inflexible type systems result in the need for type casts in order t o express the programmer's desires. At the other extreme are untyped or weakly typed languages like Smalltalk [GR83],which are prone t o run-time errors of the form "message not understood." Somewhere between these extremes are languages like Eiffel [MeygZ], which provides a conservative link-time "system validity check" to pick u p errors missed by the type checker, and Beta [MMMPSO], which builds in run-time checks t o pick u p errors which cannot be detected reliably by the type-checker.

* This research

was partially supported by NSF grant CCR-9121778.The full paper is available via anonymous ftp from cs.williams.edu in pub/kim/PolyTOIL.dvi or on the world-wide web through http://cs.williams,edu/4im. * Current address: Department of Electrical Engineering and Computer Science, University of California at Berkeley. * Current address: Department of Computer Science, Stanford University. W. Olthoff (Ed.): ECOOP '95, LNCS 952, pp. 27-51, 1995. 0 Springer-Verlag Berlin Heidelberg 1995

28

The language PolyTOIL is the culmination of a series of design efforts to build a type-safe language based on progress in the theoretical understanding of object-oriented languages. In [Bru93], we introduced a statically-typed, functional, object-oriented language, TOOPLE. This and subsequent papers [Bru94, BCK94, BCD+93] provided typing rules and both denotational and operational semantics for the language. These papers included proofs of the relative consistency of the operational and denotational semantics, a subject-reduction theorem, the type safety of the type-checking rules, and the decidability of the type-checking problem. Because most object-oriented programming languages are imperative, it was clearly desirable to extend this work to create an imperative object-oriented language. The language TOIL [BvG93, vG931 was designed to satisfy this goal while retaining the same nice features as TOOPLE. The extension of TOIL to PolyTOIL is obtained by adding an unusual form of bounded polymorphism which provides a very flexible yet safe language for object-oriented programming. In this paper we report on the design, type-checking rules, and semantics of PolyTOIL. A minimal list of features that should be supported in any object-oriented programming language includes:

- Objects, consisting of both state and operations. - Classes, to generate objects (though delegation would be a reasonable al-

-

-

ternative). Message sending, as a way of specifying computation. Instance variables, representing state. Subclasses, to support reuse of the instance variables and methods of an existing class in defining a new class. Subtypes, depending only on object interfaces, to provide a mechanism for programmers to use an object of one type in a context which expects one of a different but related type. Keywords, serf and super, representing the receiver of a message and its superclass, respectively.

Other desirable features supporting reuse include:

- Information hiding, ensuring that applications do not depend on the implementation details of objects.

- Parameterized types and (bounded) polymorphic functions, allowing a programmer to abstract over a type in order to define a related family of types or operations. - Modular type-checking, providing greater support for the reuse of class definitions by allowing subclasses to be type-checked with knowledge only of the type of the superclass, rather than its code. This provides support for separately compiled classes and eliminates the necessity of repeatedly type-checking methods when they are inherited from superclasses. The language PolyTOIL satisfies all of these requirements and is provably type safe. PolyTOIL also has the following important features.

29

PolyTOIL treats classes as first-class values, allowing them to be values of variables, to be passed as parameters, and to be returned as values of functions. This simplifies many of the problems with initializing objects and p r e vides greater flexibility in support of such things as parameterized subclasses. We also provide more flexibility in the definition of subclasses by allowing the programmer to change the types of over-ridden methods to be subtypes of the corresponding types in the superclass. Separating the subclass and subtype hierarchies in PolyTOIL allows greater expressibility while providing type safety. We introduce a new relation on types that we call “matching” which corresponds more closely than subtyping to the subclass hierarchy. This relation, which is weaker than subtyping on object types, is very useful both in expressing the type-checking rules for classes and in determining when messages can be sent to objects. The major difference between our earlier languages, TOIL (for Typed Object-oriented Imperative Language) and PolyTOIL is the support for polymorphic functions. We express constraints on type parameters by requiring that a type match a given object type. As we shall see in the next section, constraining types using matching is much more useful that using the subtype relation. While we have a number of results on the type system and semantics of PolyTOIL, in this paper we focus on type safety. We include and explain the type-checking rules as well as a natural (operational) semantics. The natural semantics is environment-based and corresponds closely to an interpreter which we have implemented for the language. We prove a subject-reduction theorem, from which follows the type safety of the system. One consequence is that the computation of a well-typed term will never result in sending a message to an object that it will not understand. The proof of subject reduction (which is included in the full paper) is interesting in that it applies to an environmentbased natural semantics for a polymorphic language. In Section 2 of this paper we discuss the design of PolyTOIL. We include an extended example which illustrates the flexibility of the language. In Section 3 we provide the formal syntax and type-checking rules for PolyTOIL. In Section 4 we provide the natural semantics and discuss the subject-reduction and typesafety theorems for PolyTOIL. In Section 5 we compare our development of PolyTOIL with other similar work on statically-typed imperative object-oriented programming languages. In the final section we discuss more recent work and future plans for PolyTOIL.

2

Language Design for Type Safety

We presume that the reader is familii with the basic notions of object-oriented languages, including object, class, subclass, method, and instance variable. Recall that type u is a subtype of type T , written u