Best Practice on design and usage of data type in Haskell [closed]

Question

My question is related to a more general question on Haskell program design. But I would like to focus on a specific use case.

I defined a data type (e.g. Foo), and used it in a function (e.g. f) through pattern matching. Later, I realized that the type (Foo) requires some additional field to support new functionalities. However, adding the field would change how the type can be used; i.e. the existing functions depending on the type could be affected. Adding new functionalities to existing code, however unappealing, is hard to avoid. I am wondering what are the best practices at the Haskell language level to minimize the impact of such kind of modifications.

For example, the existing code is:

data Foo = Foo {
  vv :: [Int]
}

f :: Foo -> Int
f (Foo v) = sum v

The function f will be syntax wrong if I add another field to Foo:

data Foo = Foo {
  vv :: [Int]
  uu :: [Int]
}

However, if I had defined function f as the following in the first place:

f :: Foo -> Int
f foo = sum $ vv foo

, then even with the modification on Foo, f would still be correct.

Answer 1

Lenses solve this problem well. Just define a lens that points to the field of interest:

import Control.Lens

newtype Foo = Foo [Int]

v :: Lens' Foo [Int]
v k (Foo x) = fmap Foo (k x)

You can use this lens as a getter:

view v :: Foo -> [Int]

... a setter:

set v :: [Int] -> Foo -> Foo

... and a mapper:

over v :: ([Int] -> [Int]) -> Foo -> Foo

The best part is that if you later change your data type's internal representation, all you have to do is change the implementation of v to point to the new location of the field of interest. If your downstream users only used the lens to interact with your Foo then you won't break backwards compatibility.

Answer 2

The best practice for processing types that might get new fields added that you want to ignore in existing code is indeed to use record selectors as you've done.

I would say that you should always define any type that might change using record notation, and you should never pattern match on a type defined with record notation using the first style with positional arguments.

Another way of expressing the above code is:

f :: Foo -> Int
f (Foo { vv = v }) = sum v

This is arguably more elegant, and it also works better in the case where Foo has multiple data constructors.