Home/ Questions/Q 3497864
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-18T12:25:27+00:00

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

  • 0

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?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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.

    • 0