Abstraction is the fundamental concept in programming languages. Modern programming languages have many forms of abstraction and Haskell typically pushes the envelope. We can abstract over types, values, data constructors, runtime representation, and perhaps soon matchability and linearity. However with configuration we seemingly threw in the towel, and just went with the bog-standard C preprocessor (CPP).

What do we mean by configuration? Configuration is the context provided at build time which decides what exactly is compiled. For example, we want to abstract over the current platform, we want to abstract over a specific package version, abstract over a cabal flag, abstract over the size of an integer and so on. A library consumer chooses one configuration of all these parameters in which to build the library.

Configuration by CPP has remained the conventional solution for a long time, and many people are aware of the superficial problems with it: dynamic scoping, lack of hygiene or namespacing, and text-based crudeness but the more insidious problem is scale. The deeper issue is that library authors typically expose a far larger space of configurations than they can ever possibly hope to test.

We can do a lot better. In particular, we now have ideas about not just for the paper cuts, but also to rename and type check all possible configurations. This talk will be an outline about how we plan to solve the configuration problem by introducing language constructs for specifying configuration options. We also hope that by presenting our initial work at HIW that we can elicit feedback from the community about the future direction of the proposal.