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).

| ||

--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:

We can pass functions to other functions:

(Here,

`map`

is a higher-order function.)Functions can produce other functions (here, by currying the

`foldr`

function):Functions can form part of other data structures:

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:

The most rudimentary way of combining them is through nesting:

Function composition gives us a more idiomatic way of combining functions:

Finally, we can abandon any reference to arguments:

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.

Haskell allows for both curried and uncurried functions:

Let's suppose that we need a function with the first argument fixed:

In both cases, we have applied one of the arguments and thereby specialized our original function. For the uncurried function we needed to mention all parameters in the reshaped function, while for the curried one we could just ignore subsequent arguments.

Since it is fairly easy to translate a curried function to an uncurried function (and vice versa) the question arises: why and when would one want to use uncurried functions?

Consider a function that returns a few pieces of data, which we choose to express as a tuple:

Then suppose we want to find the maximum value in that tuple:

This would not work because the `max`

function is curried, but we can easily align the types by uncurrying:

Whenever we have a function returning a tuple and we want to consume that tuple from a curried function, we need to uncurry that function. Alternatively, if we are writing a function to consume an output tuple from another function, we might choose to write our function in uncurried (tuple arguments) form so that we don't have to later uncurry our function or unpack the tuple.

It is idiomatic in Haskell to curry by default. There is a very important reason for this. Thanks to currying, we can do this:

We cannot, however, do this:

We need to explicitly curry `map'`

in order to compose it with other functions:

Curried functions are composable, whereas uncurried functions are not.

If we can apply one function argument at a time, nothing stops us from doing so at entirely different places in our codebase. For instance, we might "wire in" some authentication-related information into our function at one end of the codebase and use the specialized function in another part of the codebase that has no cognizance of the authentication argument and its related types.

This can be a powerful tool for decoupling, the site of decoupling being the function argument list!