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.

Abstract. The expression problem (aka the extensibility problem) refers to a fundamental dilemma of programming: To which degree can your application be structured in such a way that both the data model and the set of virtual operations over it can be extended without the need to modify existing code, without the need for code repetition and without runtime type errors. Over the years, many approaches to this problem have been proposed, each having different characteristics of type safety and reusability. While many of these rely on exotic or problem specific language extensions, this paper investigates the solution space within the framework of the soonto-be mainstream generic extensions of C # and the Java programming language. Four new solutions are presented which, though quite different, all rely on techniques that can be used in everyday programming. 1

We present a minimal core calculus that captures interesting constructs of the Scala programming language: nested classes, abstract types, mixin composition, and path dependent types. We show that the problems of type assignment and subtyping in this calculus are decidable.

This paper introduces a programming language that makes it convenient to compose large software systems, combining their features in a modular way. J & supports nested intersection, building on earlier work on nested inheritance in the language Jx. Nested inheritance permits modular, type-safe extension of a package (including nested packages and classes), while preserving existing type relationships. Nested intersection enables composition and extension of two or more packages, combining their types and behavior while resolving conflicts with a relatively small amount of code. The utility of J & is demonstrated by using it to construct two composable, extensible frameworks: a compiler framework for Java, and a peer-to-peer networking system. Both frameworks support composition of extensions. For example, two compilers adding different, domain-specific features to Java can be composed to obtain a compiler for a language that supports both sets of features.

LOOJ is an extension of Java obtained by adding bounded parametric polymorphism and new type expressions ThisClass and ThisType, which are similar to MyType in LOOM. Through examples we demonstrate the utility of this language even over very expressive extensions such as GJ. The LOOJ compiler generates standard JVML code and supports instanceof and casts for all types including type variables and the other new type expressions. The core of the LOOJ type system is sound, as demonstrated by a soundness proof for an extension of Featherweight GJ. This paper also highlights difficulties that arise from the use of both classes and interfaces as types in Java.

Abstract. The expression families problem can be defined as the problem of achieving reusability and composability across the components involved in a family of related datatypes and corresponding operations over those datatypes. Like the traditional expression problem, adding new components (either variants or operations) should be possible while preserving modular and static type-safety. Moreover, different combinations of components should have different type identities and the subtyping relationships between components should be preserved. By generalizing previous work exploring the connection between type-theoretic encodings of datatypes and visitors, we propose two solutions for this problem in Scala using modular visitor components. These components can be grouped into features that can be easily composed in a feature-oriented programming style to obtain customized datatypes and operations. 1

Abstract. The understanding of programming paradigms has not been fully established yet, though many mainstream languages, e.g. C++, Java, ML, offer more than one paradigm. This paper addresses this understanding problem through a programming experiment: considering the classic object-oriented programming (OOP) design patterns as described in the GoF book [GHJV95], we systematically look at them from the viewpoint of other paradigms, in particular the generic modular and the functional paradigms. The main results of this experiment are: (1) Many OO design pattern intents are meaningful in a more general setting than OOP, and as such they are good candidates for exploring paradigms; (2) Many OO design patterns have counterparts in generic modular programming, but with different properties, in particular with respect to dynamic/static behavior and type safety; (3) Some OOP design patterns can be implemented by using basic functional programming, justifying the idea that functional programming can also be seen as a simplified OOP having its place in a OO language; (4) Some OOP design patterns seem definitely associated with the OOP paradigm, stressing the intrinsic properties of this paradigm. 1

Much recent work in the design of object-oriented programming languages has been focusing on identifying suitable features to support so-called scalable extensibility, where the usual extension mechanism by inheritance works in different scales of software components—that is, classes, groups of classes, groups of groups and so on. Mostly, this issue has been addressed by means of dependent type systems, where nested types are seen as properties of objects. In this work, we seek instead for a different and possibly simpler solution, retaining the Java-like approach of nested types as properties of classes. We introduce the mechanism of variant path types, which provides a flexible means to intra-group relationship (among classes) that has to be preserved through extension. Featuring the new notions of exact and inexact qualifications, these types also provide rich abstractions to express various kinds of set of objects, thanks to a flexible subtyping mechanism. We formalize a safe type system for variant path types on top of Featherweight Java. Though a full study of applicability and expressiveness is ongoing work, our development currently results in a complete solution for scalable extensibility, similarly to previous attempts based on dependent type systems. 1.

the expression problem with true separate compilation

true separate compilation