Comparing Libraries for Generic Programming in Haskell Alexey Rodriguez Utrecht University, The Netherlands alexey@cs.uu.nl Johan Jeuring Utrecht University, The Netherlands johanj@cs.uu.nl Patrik Jansson Chalmers University of Technology & University of Gothenburg, Sweden patrikj@chalmers.se Alex Gerdes Open University, The Netherlands alex.gerdes@ou.nl Oleg Kiselyov FNMOC, USA oleg@pobox.com Bruno C. d. S. Oliveira Oxford University, UK bruno.oliveira@comlab.ox.ac.uk Abstract 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 partic- ular 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 characterise the many generic programming libraries in a typed functional lan- guage, we introduce a set of criteria and develop a generic program- ming 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 use- ful for reaching a common standard for generic programming, but also for a programmer who has to choose a particular approach for datatype-generic programming. Categories and Subject Descriptors D.1.1 [Programming Tech- niques]: Applicative (Functional) Programming; D.3.3 [Program- ming Languages]: Language Constructs and Features—Polymor- phism General Terms Design, Measurement Keywords datatype-generic programming, libraries comparison 1. Introduction Software development often consists of designing a datatype to which functionality is added. Some functionality is datatype specific. Other functionality is defined on almost all datatypes, and only depends on the structure of the datatype; this is called datatype-generic functionality. Examples of such functionality are comparing two values for equality, searching a value of a datatype for occurrences of a particular string or other value, editing a value, pretty-printing a value, etc. Larger examples include XML tools, testing frameworks, debuggers, and data-conversion tools. 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. Haskell’08, September 25, 2008, Victoria, BC, Canada. Copyright c  2008 ACM 978-1-60558-064-7/08/09. . . $5.00. Datatype-generic programming has been around for more than 10 years now. A lot of progress has been made in the last decade, in particular with generic programming in Haskell. There are more than 10 proposals for generic programming libraries or language extensions for Haskell. Such libraries and extensions are also start- ing to appear for other programming languages, such as ML. Although generic programming has been used in several appli- cations, it has few users for real-life projects. This is understand- able. Developing a large application takes a couple of years, and choosing a particular approach to generic programming for such a project involves a risk. Few approaches that have been developed over the last decade are still supported, and there is a high risk that the chosen approach will not be supported anymore, or that it will change in a backwards-incompatible way in a couple of years time. The Haskell Refactorer HaRe [Li et al., 2003] is an exception, and provides an example of a real-life project in which a generic- programming technique (Strafunski [L¨ ammel and Visser, 2002]) is used to implement traversals over a large abstract syntax tree. How- ever, this project contains several other components that could have been implemented using generic-programming techniques, such as rewriting, unification, and pretty-printing modules. These compo- nents are much harder to implement than traversals over abstract- syntax trees. Had these components been implemented generically, we claim that, for example, the recent work of the HaRe team to adapt the refactoring framework to the Erlang language [Der- rick and Thompson, 2005] would have been easier. Other projects that use generic programming are the Haskell Application Server (HAppS), which uses the extensible variant of Scrap Your Boil- erplate, and the Catch and Reach tools [Mitchell and Runciman, 2007a, Naylor and Runciman, 2007], which use the Uniplate li- brary to implement traversals. It is often not immediately clear which generic programming approach is best suited for a particular project. There are generic functions that are difficult or impossible to define in certain ap- proaches. The datatypes to which a generic function can be applied, and the amount of work a programmer has to do per datatype and/or generic function varies among different approaches. The current status of generic programming in Haskell is com- parable to the lazy Tower of Babel preceding the birth of Haskell in the eighties [Hudak et al., 2007]. We have many single-site lan- guages or libraries, each individually lacking critical mass in terms of language/library-design effort, implementations, and users. How can we decrease the risk in using generic programming? Our eventual goal is to design a common generic programming library for Haskell. To increase the chances of continuing sup-