PolyTOIL is a new statically-typed polymorphic object-oriented programming language that is provably type-safe. By separating the de nitions of subtyping and inheritance, providing a name for the type of self, and carefully de ning the type-checking rules, we have obtained a language that is very expressive while supporting modular type-checking of classes. The matching relation on types, which is related to F-bounded quanti cation, is used both in stating type-checking rules and expressing the bounds on type parameters for polymorphism. The design of PolyTOIL is based on a careful formal de nition of type-checking rules and semantics.

Recent years have seen the development of several foundational models for statically typed object-oriented programming. But despite their intuitive similarity, di erences in the technical machinery used to formulate the various proposals have made them di cult to compare. Using the typed lambda-calculus F! as a common basis, we nowo er a detailed comparison of four models: (1) a recursive-record encoding similar to the ones used by Cardelli [Car84],

We design and study νObj, a calculus and dependent type system for objects and classes which can have types as members. Type members can be aliases, abstract types, or new types. The type system can model the essential concepts of Java's inner classes as well as virtual types and family polymorphism found in BETA or gbeta. It can also model most concepts of SML-style module systems, including sharing constraints and higher-order functors, but excluding applicative functors. The type system can thus...

Multimethods offer several well-known advantages over the single dispatching of conventional object-oriented languages, including a simple solution to the binary method problem, a natural implementation of the strategy design pattern, and a form of open objects that enables easy addition of new operations to existing classes. However, previous work on statically typed multimethods whose arguments are treated symmetrically has required the whole program to be available in order to perform typechecking. We describe Dubious, a simple core language including first-class generic functions with symmetric multimethods, a classless object model, and modules that can be separately typechecked. We identify two sets of restrictions that ensure modular type safety for Dubious as well as an interesting intermediate point between these two. We have proved each of these modular type systems sound.

Inheritance is a useful mechanism for factoring and reusing code. However, it has limitations for building extensible systems. We describe nested inheritance, a mechanism that addresses some of the limitations of ordinary inheritance and other code reuse mechanisms. Using our experience with an extensible compiler framework, we show how nested inheritance can be used to construct highly extensible software frameworks. The essential aspects of nested inheritance are formalized in a simple object-oriented language with an operational semantics and type system. The type system of this language is sound, so no run-time type checking is required to implement it and no run-time type errors can occur. We describe our implementation of nested inheritance as an unobtrusive extension of the Java language, called Jx. Our prototype implementation translates Jx code to ordinary Java code, without duplicating inherited code.

Cecil is a purely object-oriented language intended to support rapid construction of high-quality, extensible software. Cecil combines multi-methods with a simple classless object model, a kind of dynamic inheritance, modules, and optional static type checking. Instance variables in Cecil are accessed solely through messages, allowing instance variables to be replaced or overridden by methods and vice versa. Cecil’s predicate objects mechanism allows an object to be classified automatically based on its run-time (mutable) state. Cecil’s static type system distinguishes between subtyping and code inheritance, but Cecil enables these two graphs to be described with a single set of declarations, streamlining the common case where the two graphs are parallel. Cecil includes a fairly flexible form of parameterization, including explicitly parameterized objects, types, and methods, as well as implicitly parameterized methods related to the polymorphic functions commonly found in functional languages. By making type declarations optional, Cecil aims to allow mixing of and migration between exploratory and production programming styles. Cecil supports a module mechanism that enables independently-developed subsystems to be encapsulated, allowing them to be type-checked and reasoned about in isolation despite the presence of multi-methods and subclassing. Objects can be extended externally with additional

Aspects have emerged as a powerful tool in the design and development of systems, allowing for the encapsulation of program transformations. The dynamic semantics of aspects is typically specified by appealing to an underlying object-oriented language via a compiler transformation known as weaving.

In a call-by-value language, representing objects as recursive records requires using an unsafe fixpoint. We design, for a core language including extensible records, a type system which rules out unsafe recursion and still supports the reconstruction of a principal type. We illustrate the expressive power of this language with respect to object-oriented programming by introducing a sub-language for "mixin-based" programming.

The expression problem is fundamental for the development of extensible software. Many (partial) solutions to this problem have been proposed in the past, but the question of how to use different, independent extensions jointly has received less attention so far. This paper proposes solutions to the expression problem that make it possible to combine independent extensions in a flexible, modular, and typesafe way. The solutions, formulated in the programming language Scala, are affected with only a small implementation overhead and are relatively easy to implement by hand. 1. The Expression Problem Since software evolves over time, it is essential for software systems to be extensible. But the development of extensible software poses many design and implementation problems, especially, if extensions cannot be anticipated. The expression problem is probably the most fundamental one among these problems. It arises when recursively defined datatypes and operations on these types have to be extended simultaneously. The term expression problem was originally coined by Phil Wadler in a post on the Java-Genericity mailing list [34], although it was Cook who first discussed this problem [9]. His work motivated several others to reason about variants of the problem in the following years [18, 27, 17, 12]. In his post to the Java-Genericity mailing list, Wadler also proposed a solution to the problem written in an extended version of GENERIC JAVA [3]. Only later it appeared that this solution could not be typed. For this paper, we paraphrase the problem in the following way: Suppose we have a datatype which is defined by a Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.

Kim B. Bruce 1,2 Department of Computer Science Williams College Williamstown, MA 01267, U.S.A.