Bλog

Links

On Ad-hoc Datatypes

Use ad-hoc datatypes liberally to improve code readability
Published on May 11, 2016 under the tag haskell

In Haskell, it is extremely easy for the programmer to add a quick datatype. It does not have to take more than a few lines. This is useful to add auxiliary, ad-hoc datatypes.

I don’t think this is used enough. Most libraries and code I see use “heavier” datatypes: canonical and very well-thought-out datatypes, followed by dozens of instances and related functions. These are of course great to work with, but it doesn’t have to be a restriction: adding quick datatypes – without all these instances and auxiliary functions – often makes code easier to read.

The key idea is that, in order to make code as simple as possible, you want to represent your data as simply as possible. However, the definition of “simple” is not the same in every context. Sometimes, looking at your data from another perspective makes specific tasks easier. In those cases, introducing “quick-and-dirty” datatypes often makes code cleaner.

This blogpost is written in literate Haskell so you should be able to just load it up in GHCi and play around with it. You can find the raw .lhs file here.

This is not very nice. The business logic is interspersed with the printing code. We could clean it up by adding additional predicates such as cartIsBonus, but having too many of these predicates leads to a certain kind of Boolean Blindness.

Note that we now have a single location where we classify the cart. This is useful if we need this information in multiple places. If we chose to solve the problem by adding additional predicates such has cartIsBonus instead, we would still have to watch out that we check these predicates in the same order everywhere. Furthermore, if we need to add a case, we can simply add a constructor to this datatype, and the compiler will tell us where we need to update our code 1.