Haskell data types usage good practicies

Question

Reading "Real world Haskell" i found some intresting question about data types:

This pattern matching and positional data access make it look like you have very tight coupling between data and code that operates on it (try adding something to Book, or worse change the type of an existing part).

This is usually a very bad thing in imperative (particularly OO) languages... is it not seen as a problem in Haskell? source at RWH comments

And really, writing some Haskell programs I found that when I make small change to data type structure it affects almost all functions that use that data type. Maybe there are some good practices for data type usage. How can i minimize code coupling?

Answer 1

What you are describing is commonly known as the expression problem -- http://en.wikipedia.org/wiki/Expression_Problem.

There is a definite trade-off to be made, haskell code in general, and algebraic data types in particular, tends to fall into the hard to change the type but easy to add functions over the type. This optimizes for (up front) well-designed, complete, data types.

All that said, there are a number of things that you can do to reduce the coupling.

• Define good library functions, by defining a complete set of combinators and higher order functions that are useful for interacting with your data type you will reduce coupling. It is often said that when ever you think of pattern matching there is a better solution using higher-order functions. If you look for these situations you will be in a better spot.

• Expose your data structures as more abstract types. This means implementing all appropriate type classes. This will assist with defining a library functions as you will get a bunch for free with any of the type classes you implement, for examples look at operations over Functor or Monad.

• Hide (as much as possible) any type constructors. Constructors expose implementation detail and will encourage coupling. Hint: this links in with defining a good api for interacting with your type, consumers of your type should rarely, if ever, have to use the type constructors.

The haskell community seems particularly good at this, if you look at many of the libraries on hackage you will find really good examples of implementing type classes and exposing good library functions.

Answer 2

In addition to what's been said:

One interesting approach is the "scrap your boilerplate" style of defining functions over data types, which makes use of generic functions (as opposed to explicit pattern matching) to define functions over the constructors of a data type. Looking at the "scrap your boilerplate" papers, you will see examples of functions which can cope with changes to the structure of a data type.

A second method, as Hibberd pointed out, is to use folds, maps, unfolds, and other recursion combinators, to define your functions. When you write functions using higher order functions, oftentimes small changes to the underlying data type can be dealt with in the instance declarations for Functor, Foldable, and so on.

Answer 3

First, I'd like to mention that in my view, there are two kinds of couplings:

• One that makes your code cease to compile when you change one and forget to change the other

• One that makes your code buggy when you change one and forget to change the other

While both are problematic, the former is significantly less of a headache, and that seems to be the one you're talking about.

I think the main problem you're mentioning is due to over-using positional arguments. Haskell almost forces you to have positional arguments in your ordinary functions, but you can avoid them in your type products (records).

Just use records instead of multiple anonymous fields inside data constructors, and then you can pattern-match any field you want out of it, by name.

bad (Blah _ y) = ...

good (Blah{y = y}) = ...

Avoid over-using tuples, especially those beyond 2-tuples, and liberally create records/newtypes around things to avoid positional meaning.