Generic programming is a strangely overloaded concept. For example, it is used by different programming language communities to essentially mean “the kind of polymorphism this language cannot easily express.” The computer algebra community uses the term to mean abstraction over algebraic structures. For C++ programmers, it means template metaprogramming. And for Haskell programmers, it means “datatype-generic” or “polytypic” functions, which work over families of types rather than parametrically. Other communities have defined their own versions, which always boil down to “the polymorphism we wish we had.”

In the Haskell world, the repetition of the same code at different types is colloquially known as boilerplate. Thus, the effort to introduce techniques to eliminate such code repetition became known as the “scrap your boilerplate” approach [1]. In the last few years, this approach has been greatly studied and expanded by the authors, who were able to assemble a great amount of knowledge and extract from it the core structures and ideas involved. The end result is this survey paper.

The work, while not entirely Haskell specific, is firmly aimed at this community. Readers will need a solid understanding of Haskell to grasp the vastness of the terrain covered. For these readers, the result is a well-paced and well-organized survey of numerous tools and techniques for achieving various kinds of “genericity.” After a high-level overview of the problem, the rest of the paper is organized around the themes of support for overloading, runtime type representation, and a generic view of data.

Each theme is clearly explained and a careful Socratic approach is used to illustrate the solutions, as well as the pitfalls. Explicit code is used throughout, to ground the theoretical discussion with specific examples. Key to a number of the techniques is to reflect types into the value language, and then reify type-level structures as names, allowing intensional operations that are otherwise impossible in statically typed languages.

The only critique I have is that the authors implicitly assume that their three themes are the right modularization of the design space of generic programming in Haskell. While this might be a correct assumption, the point is not properly justified. Otherwise, the authors’ mastery of the topic is exemplary, as is their skillful exposition.