Datatype-generic programming is defining functions that depend on the structure, or “shape”, of datatypes. It has been around for more than 10 years, and a lot of progress has been made, in particular in the lazy functional programming language Haskell. There are more than 10 proposals for generic programming libraries or language extensions for Haskell. To compare and characterize the many generic programming libraries in a typed functional language, we introduce a set of criteria and develop a generic programming benchmark: a set of characteristic examples testing various facets of datatype-generic programming. We have implemented the benchmark for nine existing Haskell generic programming libraries and present the evaluation of the libraries. The comparison is useful for reaching a common standard for generic programming, but also for a programmer who has to choose a particular approach for datatype-generic programming.

Abstract. Reynolds ’ abstraction theorem [21], often referred to as the parametricity theorem, can be used to derive properties about functional programs solely from their types. Unfortunately, in the presence of runtime type analysis, the abstraction properties of polymorphic programs are no longer valid. However, runtime type analysis can be implemented with term-level representations of types, as in the λR language of Crary et al. [10], where case analysis on these runtime representations introduces type refinement. In this paper, we show that representation-based analysis is consistent with type abstraction by extending the abstraction theorem to such a language. We also discuss the “free theorems” that result. This work provides a foundation for the more general problem of extending the abstraction theorem to languages with generalized algebraic datatypes (gadts). 1

Abstract not found

Aspect-Oriented Programming (AOP) aims at modularising crosscutting concerns that show up in software. The success of AOP has been almost viral and nearly all areas in Software Engineering and Programming Languages have become “infected ” by the AOP bug in one way or another. Interestingly the functional programming community (and, in particular, the pure functional programming community) seems to be resistant to the pandemic. The goal of this paper is to debate the possible causes of the functional programming community’s resistance and to raise awareness and interest by showcasing the benefits that could be gained from having a functional AOP language. At the same time, we identify the main challenges and explore the possible design-space. Categories and Subject Descriptors D.3.2 [Programming Languages]: Language Classifications—Applicative (functional) languages,

Some programs are doubly-generic. For example, map is datatypegeneric in that many different data structures support a mapping operation. A generic programming language like Generic Haskell can use a single definition to generate map for each type. However, map is also arity-generic because it belongs to a family of related operations that differ in the number of arguments. For lists, this family includes repeat, map, zipWith, zipWith3, zipWith4, etc. With dependent types or clever programming, one can unify all of these functions together in a single definition. However, no one has explored the combination of these two forms of genericity. These two axes are not orthogonal because the idea of arity appears in Generic Haskell: datatype-generic versions of repeat, map and zipWith have different arities of kind-indexed types. In this paper, we define arity-generic datatype-generic programs by building a framework for Generic Haskell-style generic programming in the dependently-typed programming language

Datatype-generic programming is about defining functions that depend on the structure, or “shape”, of datatypes. It has been around for more than 10 years, and a lot of progress has been made, in particular in the lazy functional programming language Haskell. There are more than 10 proposals for generic programming libraries or language extensions for Haskell. In this paper we compare and characterise the many generic programming libraries for Haskell. To that end, we introduce a set of criteria and develop a generic programming benchmark: a set of characteristic examples testing various facets of datatype-generic programming. We have implemented the benchmark for ten existing Haskell generic programming libraries and present the evaluation of the libraries. The comparison is useful for reaching a common standard for generic programming, but also for a programmer who has to choose a particular approach for datatype-generic programming.

Datatype-generic programming is parametrizing programs by the structure, or “shape ” of datatypes, letting us write, for example, generic traversal or pretty-printing once and apply them to any data type whose shape we can represent. Although more than two decades old, the field has been vigorously growing in recent years, particularly in Haskell. There are more than ten datatype-generic programming libraries in Haskell, not counting proposed language extensions. The proliferation of the libraries poses the problem of comparing them, to help the users choose the right library for their tasks and to attempt to unify some of them. In this paper we develop an extensive test suite for comparing datatype-generic libraries in a typed functional language. We introduce a broad set of criteria and develop a collection of characteristic examples covering most of the facets of datatype-generic programming. We have implemented the examples for ten existing Haskell generic programming libraries and report for the first time the comprehensive evaluation of the libraries against the broad common standard. ZU064-05-FPR ComparingJournal 21 June 2011 16:28 2 Rodriguez Yakushev et al. 1