Module and class systems have evolved to meet the demand for reuseable software components. Considerable effort has been invested in developing new module and class systems, and in demonstrating how each promotes code reuse. However, relatively little has been said about the interaction of these constructs, and how using modules and classes together can improve programs. In this paper, we demonstrate the synergy of a particular form of modules and classes—called units and mixins, respectively—for solving complex reuse problems in a natural manner.

We present a new predicative and decidable type system, called ML , suitable for languages that integrate functional programming and parametric polymorphism in the tradition of ML [21, 28], and class-based objectoriented programming and higher-order multi-methods in the tradition of CLOS [12]. Instead of using extensible records as a foundation for object-oriented extensions of functional languages, we propose to reinterpret ML datatype declarations as abstract and concrete class declarations, and to replace pattern matching on run-time values by dynamic dispatch on run-time types. ML is based on universally quantified polymorphic constrained types. Constraints are conjunctions of inequalities between monotypes built from type constructors organized into extensible and partially ordered classes. We give type checking rules for a small, explicitly typed functional language `a la XML [20] with multi-methods, show that the resulting system has decidable minimal types, and discuss subject ...

Objective ML is a small practical extension to ML with objects and top level classes. It is fully compatible with ML; its type system is based on ML polymorphism, record types with polymorphic access, and a better treatment of type abbreviations. Objective ML allows for most features of object-oriented languages including multiple inheritance, methods returning self and binary methods as well as parametric classes. This demonstrates that objects can be added to strongly typed languages based on ML polymorphism.

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.

A major problem for writing extensible software arises when recursively defined datatypes and operations on these types have to be extended simultaneously without modifying existing code. This paper introduces Extensible Algebraic Datatypes with Defaults which promote a simple programming pattern to solve this well known problem. We show that it is possible to encode extensible algebraic datatypes in an object-oriented language, using a new design pattern for extensible visitors. Extensible algebraic datatypes have been successfully applied in the implementation of an extensible Java compiler. Our technique allows for the reuse of existing components in compiler extensions without the need for any adaptations.

Type dispatch constructs are an important feature of many programming languages. Scheme has predicates for testing the runtime type of a value. Java has a class cast expression and a try statement for switching on an exception's class. Crucial to these mechanisms, in typed languages, is type refinement: The static type system will use type dispatch to refine types in successful dispatch branches. Existing work in functional languages has addressed certain kinds of type dispatch, namely, intensional type analysis. However, this work does not extend to languages with subtyping nor to named types. This paper describes a number of type dispatch constructs that share a common theme: class cast and class case constructs in object oriented languages, ML style exceptions, hierarchical extensible sums, and multimethods. I describe a unifying mechanism, tagging, that abstracts the operation of these constructs, and formalise a small tagging language. After discussing how to implement the tagging...

One promising approach for adding object-oriented (OO) facilities to functional languages like ML is to generalize the existing datatype and function constructs to be hierarchical and extensible, so that datatype variants simulate classes and function cases simulate methods. This approach allows existing datatypes to be easily extended with both new operations and new variants, resolving a longstanding conflict between the functional and OO styles. However, previous designs based on this approach have been forced to give up modular typechecking, requiring whole-program checks to ensure type safety. We describe Extensible ML (EML), an ML-like language that supports hierarchical, extensible datatypes and functions while preserving purely modular typechecking. To achieve this result, EML’s type system imposes a few requirements on datatype and function extensibility, but EML is still able to express both traditional functional and OO idioms. We have formalized a core version of EML and proven the associated type system sound, and we have developed a prototype

Programming languages offer a variety of constructs to support code reuse. For example, functional languages provide function constructs for encapsulating expressions to be used in multiple contexts. Similarly, object-oriented languages provide class (or class-like) constructs for encapsulating sets of definitions that are easily adapted for new programs. Despite the variety and abundance of such programming constructs, however, existing languages are ill-equipped to support component programming with reusable software components. Component programming differs from other forms of reuse in its emphasis on the independent development and deployment of software components. In its ideal form, component programming means building programs from off-the-shelf components that are supplied by a software-components industry. This model suggests a strict separation between the producer and consumer of a component. The separation, in turn, implies separate compilation for components, allowing a pr...

This paper describes a simple means for encoding classes in Object ML (OML) [RR96] using the Standard ML (SML) module system [Mac86]. In previous work [RR96], we showed how to mimic class-based implementation inheritance in some simple cases, but we did not know how to extend that to all methods (we had problems with methods that return "self"). This paper describes a general encoding of class-based implementation inheritance in OML, using the SML module system [Mac86]. In addition to handling all methods, we also show how to encode other various class-based features, such as static members, protected members, and multiple inheritance. OML extends SML with support for simple objects and subtyping. Following Abadi and Cardelli [AC95], objects are constructed directly, and methods take a "self" parameter that, upon method invocation, is bound to the object itself. In contrast to Abadi and Cardelli's system, OML requires declarations of the subtyping hierarchy and the interface types of objects. These declarations also introduce unique object constructors

The Haskell dialect Mondrian is designed using the explicit philosophy of keeping things simple and consistent. Mondrian generalizes some of Haskell's (too) complex constructs, and adds a few simple new ones. This results in a small, intuitively comprehensible language with an object oriented flavor. In this paper, we will present the design decisions we made for Mondrian. Furthermore, some of Mondrian's language constructs will be defined by translations into Haskell. 1 Introduction In the preface of the Haskell report [13] the hope is expressed that extensions or variants of the language will appear that incorporate experimental features. The language Mondrian is such an experiment. Mondrian evolved from Haskell by deleting and combining some of Haskell's more complicated constructs and adding a few simple new ones. Unlike the language Pizza [29], which is designed as a strict superset of Java [8], the major concern in designing Mondrian has been to keep the language as basic and do...