WASP Washington Advanced Systems for Programming

Diamond: A Language for Modules and Objects

Diamond is an object-oriented language we are using to investigate novel module systems. The current incarnation of Diamond combines ML-style parameterized modules (functors), object-oriented extensibility, and flexible type abstraction.

Diamond extends our group's previous work on modular extensibility in the EML, MultiJava, and Relaxed MultiJava languages. We also plan to use a variant of the Diamond core calculus to guide the design of Diesel.

Motivation:

A module system is a mechanism for combining discrete pieces of software (modules) into a larger piece of software. A good module system should support the following software engineering goals:

Local reasoning: Programmers shouldn't have to think about the whole program in order to write a part of it. Programmers should be able to program modules against strong, statically checked interfaces that abstractly describe the rest of the program.

Programmers shouldn't have to think about the whole program in order to write a part of it. Programmers should be able to program modules against strong, statically checked interfaces that abstractly describe the rest of the program. Code reuse: Programmers shouldn't have to repeat themselves. Programmers should be able to write a piece of code once, and use the module system's composition mechanisms to extend or adapt that code to many purposes.

Many programming languages support object-oriented extensibility --- the ability both to add new subclasses to existing data types, and to add overriding methods to existing functions. However, object-oriented programming languages have struggled to provide these features while supporting adequate modules. The traditional solution has been either to provide a weak module system, to impose highly restrictive limitations on extensibility, or both.

In particular, no previous language has combined good support for symmetric multiple dispatch and parameterized modules. By integrating all these features, we are able to cleanly support a variety of useful programming idioms, including mixins and most of the traditional uses of parameterized classes (generics).

Key technical challege:

Providing these features in purely unrestricted form can lead to unsound modular type checking, and therefore runtime errors. The challenge is in devising a set of restrictions and type-theoretic mechanisms that together preserve the useful programming idioms while ruling out unsoundness.

Status:

A paper describing F(EML), a successor to EML, will appear in ECOOP 2006. A preprint PDF is available.

A preliminary presentation on F(EML) appeared in the FOOL/WOOD 2006 workshop. This version is deprecated.

Contacts: