• previous -- Applicatives (advanced)
• table of contents
• next -- RWH chapter 10

Haskell for Hobos-- Monads

Understanding monads is a vital aspect of really understanding Haskell.

Don't be frightened by all these new words, functor, monad, and so on. Also don't be frightened by fancy new operators like <$>, <*> and such. All these things are really generalizations of good old "map" and lists, so keeping that in mind will be helpful.

First of all "Monad" is a typeclass not a type. Many things in Haskell are monads. (Sometimes it seems everything in Haskell is a monad.) Lists are monads. Maybe is a monad. IO is a monad.

Second of all, Monads are not restricted in some way to doing IO. Monads are quite important to IO given how IO works in Haskell, but it is a mistake to think that Monads are an "IO thing". It is also a mistake (and a more common one) to think that do notation is a special thing for IO. Do notation is most commonly used in connection with IO in most programs, but do notation is a general thing used to work with monads.

To avoid this generating or reinforcing this IO and monad confusion, it try my best to avoid talking about IO in this document. At least I limit my use of IO as a monad for the sake of illustration.

For the purpose of understanding monads, I find it useful to view the types that participate in the monad game as containers or boxes. Or to view the types as having a certain smell or flavor. We want to operate on the things in the boxes, keeping the smell.

Review

Taking a list an an example, consider a list of integers. Perhaps we want to apply a function that operates on integers to the list. That function demands an integer argument, but the list has the type of "list" so we can't directly apply the function. What are we to do?

To solve this problem for lists, we have "map". Understanding map is a vital first step to understanding all of this. However map only works on lists (and map can only apply a function that takes a single argument).

To generalize map, we invent functors which give us "fmap". We can use fmap in place of map to work on lists, but this doesn't really buy us anything. But we can use fmap to operate on the Maybe type and that is new and powerful.

A further generalization (and a bit of a step sideways) is an applicative (short for applicative functor). It allows us to take a function in a box and apply it some other thing in a box and get a new thing in a box. This allow an applicative to work with functions with more than one argument, which is the benefit over plain old functors.

On to monads

As with many things in Haskell, a big part of the challenge is dealing with a high level of abstraction. I think one of the best ways to deal with this is to show you these abstract things in action using examples.

Let's start by looking at the actual definition of the Monad typeclass. It looks something like this:

class Monad m where
	(>>=) :: m a -> (a -> m b) -> m b
	(>>) :: m a -> m b -> m b
	return :: a -> m a

Notice the "return" operator. I find this a bizarre choice of a name, that seems almost a diabolical attempt to confuse us because it is nothing like what return does in any other language. What return does is to simply wrap some basic type into a monad. I might have chosen the word "wrap" or "inject". It is exactly the same a "pure" in Applicatives.

The (>>=) operator (sometimes called "bind" or "chain") is the heart of the issue. It's first argument is some thing "a" wrapped as a monad. The second argument is a function, which takes an unwrapped "a" and gives us a wrapped "b". The operator yields the "b" wrapped as a monad.

It is not unlike "map" except here we have this awkward function that takes an unwrapped value, transforms it, and give it to us as a wrapped value. Now we need to see all this in action. Here is a silly demonstration:

lucky x = Just (x+13)
output = Just 100 >>= lucky

main = putStrLn $ show output

First I want a function that takes an ordinary thing and wraps it into a Monad. I choose the Maybe type as my monad and the function just adds 13 to the argument and wraps it using Just.

Next we concoct a Maybe monad using "Just 100" and then feed it to our function using the "bind" operator (>>=). This seemed to follow my understanding of things as described above, and much to my surprise it works. I'll note in passing that this "feels" like a pipeline. We are feeding a monad into a function and getting a monad out. We could continue in this way if we had another function

lucky x = Just (x+13)
greedy x = Just (x*100)
output = Just 100 >>= lucky >>= greedy

main = putStrLn $ show output

Hold on now a minute! You may be thinking that now you know all there is to know about how the monad game works. But that ain't so. Remember that there is more to a Maybe than just wrapping a value inside of Just. Don't forget that we need to handle the value "Nothing". Let's see how that works.

trouble _ = Nothing
lucky x = Just (x+13)
greedy x = Just (x*100)
output = Just 100 >>= trouble >>= lucky >>= greedy

main = putStrLn $ show output

Nothing

Other types will need to define the operator in a way that is appropriate to make this magic work. A list is a monad. How does it define the >>= operator?

What about list as a Monad?

bloat x = [ x, 10*x]
outlist = [ 1, 2, 3 ] >>= bloat

main = putStrLn $ show outlist
[1,10,2,20,3,30]

Haskell has a function named "concatMap" to do just this (who would have known). The point here is that every type which is a Monad has its own particular implementation of >>=, hopefully designed with good sense.

Monads everywhere

comp = [1, 2] >>= \x -> return (x)
comp = [1, 2] >>= \x -> return x

comp = [1, 2] >>= \x -> [10, 20] >>= \y -> return (x * y)

What is particularly interesting is that this is equivalent to the following list comprehension:

[x * y | x <- [1, 2], y <- [10, 20]]

A side note on return

lucky x = return (x+13)

lucky :: Num a => a -> Maybe a
lucky x = return (x+13)

Some monads are used simply for their side effects. (Yes, I know, Haskell is supposed to be pure and not have side effects). The usual example would be IO. In that case the return value of the monad would be irrelavant and could be almost anything. The convention in such cases is for the monad to yield the value (). Yep, and empty tuple. You will often see "return ()" used in such cases, which serves to even more strongly confuse and mislead people used to programming in other languages.

And what about that >> operator?

Sometimes >> is called "then". It sequences two monadic actions together, just like >>= but it throws away the result of the first action. The following defines it in terms of >>=, which we think we understand.

k >> f = k >>= \_ -> f

main = putStrLn "Hello" >> putStrLn "World"

Hello
World

Do notation

Suppose we have 4 monadic operations we want to sequence. We can write:

a >> b >> c >> d

do a
   b
   c
   d

a >>= (b >>= (c >>= d))

do tmp1 <- a
   tmp2 <- b tmp1
   tmp3 <- c tmp2
   d tmp3

Do notation deserves a whole section of its own, which I will make every effort to provide elsewhere.

Some closing comments

We can talk all day about things in container or boxes, but that won't get us any closer to understanding Monads (or any typeclass). The way to understand a typeclass is to take a close look at the operators that the typeclass introduces. In the case of Monads this is >>= (as well as >>).

Some monad essays

• You could have invented Monads (PDF)
• You could have invented Monads

• previous -- Applicatives (advanced)
• table of contents
• next -- RWH chapter 10