Software design patterns were forged at a time when object oriented programming (OOP) reigned. This led to "design patterns" becoming somewhat synonymous with "OOP design patterns". But design patterns are solutions to problems and problems are relative to the context in which they occur. A design problem in OOP is not necessarily one in functional programming (FP), and vice versa.
From a Haskell perspective, many (but not all) of the well known "Gang of Four" patterns [Design patterns, Gamma et al.] become so easy to solve that it is not worth going to the trouble of treating them as patterns.
However, we still want to identify patterns of problems and solutions, so that when we have a dejavu moment of having experienced a problem before, we are somewhat prepared. Design patterns remain relevant for Haskell, after all, "dejavu is language neutral" (Erich Gamma).
Modularity means more than modules. Our ability to de-compose a problem into parts depends directly on our ability to glue solutions together. To support modular programming, a language must provide good glue." | ||
| --Why Functional Programming Matters - John Hughes | ||
In order to have a meaningful conversation about Haskell design patterns, we'll begin our exploration by looking at the three primary kinds of "glue" in Haskell: first-class functions, the Haskell type system, and lazy evaluation. This chapter revisits the Haskell you already know through the lens of design patterns, and looks at:
- Higher-order functions
- Currying
- Recursion
- Types, pattern matching, polymorphism
- Lazy Evaluation
- Monads
Functions are our first kind of "glue" in Haskell.
Haskell functions are first-class citizens of the language. This means that:
- We can name a function just as we can name any primitive value:
square = x -> x * x
- We can pass functions to other functions:
map square [1, 3, 5, 7]
(Here,
mapis a higher-order function.) - Functions can produce other functions (here, by currying the
foldrfunction):sum = foldr (+) 0
- Functions can form part of other data structures:
let fs = [(* 2), (* 3), (* 5)] zipWith (f v -> f v) fs [1, 3, 5]
This places Haskell functions on an equal footing with primitive types.
Let's compose these three functions, f, g, and h, in a few different ways:
f, g, h :: String -> String
The most rudimentary way of combining them is through nesting:
z x = f (g (h x))
Function composition gives us a more idiomatic way of combining functions:
z' x = (f . g . h) x
Finally, we can abandon any reference to arguments:
z'' = f . g . h
This leaves us with an expression consisting of only functions. This is the "point-free" form.
Programming with functions in this style, free of arguments, is called tacit programming.
It is hard to argue against the elegance of this style, but in practice, point-free style can be more fun to write than to read: it can become difficult to infer types (and, therefore, meaning). Use this style when ease of reading is not overly compromised.