Their support for code reuse has made object-oriented languages popular. However, they do not succeed equally in all areas, particularly when data has a complex structure, making hard to keep the parallel between data and code. On the other hand, functional programming languages, which separate data from code, are better at handling complex structures, but they do not provide direct ways to reuse code for a different datatype. We show here a way to achieve code reuse, even when data and code are separated. The method is illustrated by a detailed example. 1

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.

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.

Abstract. ADDS is our proposal for the development of content-intensive applications. Applications in ADDS are produced by processing documents that describe their main aspects and that have been marked up using application-dependent, Domain-Specific Markup Languages (DSMLs). To make ADDS of practical value, we promote the incremental definition of DSMLs, as well as their incremental operationalization (i.e. the incremental construction of their processors). In this paper we describe how this incremental definition is carried out by using a technique called PADDS (DSML Provision in ADDS), and how incremental operationalization is accomplished using a model called OADDS (Operationalization in ADDS).

the expression problem with true separate compilation

Static and dynamic type systems have well-known strengths and weaknesses. Gradual typing provides the benefits of both in a single language by giving the programmer control over which portions of the program are statically typed and which portions are dynamically checked based on the presence or absence of type annotations. A compiler for a gradually typed language infers where the dynamic checks are needed and inserts casts into the intermediate language to perform these checks. Herman, Tomb, and Flanagan noticed that casts in higher-order languages can cause space leaks proportional to the execution time of the program. They developed a solution that merges sequences of casts. On a separate front, Findler and Wadler developed blame tracking for a language similar to the intermediate language of gradual typing. Blame tracking solves the problem of tracing a run-time cast failure back to the source of the error. Findler and Wadler proved that well-typed portions of a program can’t be blamed. Blame tracking requires extra information to be stored in casts and whether this information can be merged to obtain space efficiency is an open question. This paper answers the question in the affirmative by developing a dynamic semantics for gradual types that is both space efficient and tracks blame. This paper also improves the precision of blame tracking by reporting what part of the cast caused the error.