A monad is more of a design pattern than a data structure. That is, there are many data structures that, if you look at them in the right way, turn out to be monads.
The name "monad" comes from the mathematical field of category theory, which studies abstractions of mathematical structures. If you ever take a PhD level class on programming language theory, you will likely encounter that idea in more detail. Here, though, we will omit most of the mathematical theory and concentrate on code.
Monads became popular in the programming world through their use in Haskell, a functional programming language that is even more pure than OCaml—that is, Haskell avoids side effects and imperative features even more than OCaml. But no practical language can do without side effects. After all, printing to the screen is a side effect. So Haskell set out to control the use of side effects through the monad design pattern. Since then, monads have become recognized as useful in other functional programming languages, and are even starting to appear in imperative languages.
Monads are used to model computations. Think of a computation as being like a function, which maps an input to an output, but as also doing "something more." The something more is an effect that the function has as a result of being computed. For example, the effect might involve printing to the screen. Monads provide an abstraction of effects, and help to make sure that effects happen in a controlled order.
The Monad Signature
For our purposes, a monad is a structure that satisfies two properties. First, it must match the following signature:
module type Monad = sig type 'a t val return : 'a -> 'a t val bind : 'a t -> ('a -> 'b t) -> 'b t end
Second, a monad must obey what are called the monad laws. We will
return to those much later, after we have studied the
Think of a monad as being like a box that contains some value. The
value has type
'a, and the box that contains it is of type
We have previously used a similar box metaphor for both options
and promises. That was no accident: options and promises are both
examples of monads, as we will see in detail, below.
return operation metaphorically puts a value into a box. You can
see that in its type: the input is of type
'a, and the output is
In terms of computations,
return is intended to have some kind of
trivial effect. For example, if the monad represents computations
whose side effect is printing to the screen, the trivial effect would
be to not print anything.
bind operation metaphorically takes as input:
- a boxed value, which has type
'a t, and
- a function that itself takes an unboxed value of type
'aas input and returns a boxed value of type
'b tas output.
bind applies its second argument to the first. That requires
'a value out of its box, applying the function to it, and
returning the result.
In terms of computations,
bind is intended to sequence effects one
after another. Continuing the running example of printing, sequencing
would mean first printing one string, then another, and
be making sure that the printing happens in the correct order.
The usual notation for
bind is as an infix operator written
still pronounced "bind". So let's revise our signature for monads:
module type Monad = sig type 'a t val return : 'a -> 'a t val (>>=) : 'a t -> ('a -> 'b t) -> 'b t end
All of the above is likely to feel very abstract upon first reading.
It will help to see some concrete examples of monads. Once you understand
return operations, the design pattern itself should
make more sense.
So the next few sections look at several different examples of code in which monads can be discovered. Because monads are a design pattern, they aren't always obvious; it can take some study to tease out where the monad operations are being used.