The Monad typeclass is best understood by looking at it from many perspectives. That is why this book has no definitive section or chapter on Monad. Instead, we will successively peel off the layers of this abstraction.

Let's begin by looking at a simple example of interpreting expressions:

data Expr = Lit Int | Div Expr Expr

eval :: Expr -> Int
eval (Lit a) = a
eval (Div a b) = eval a `div` eval b

The eval function interprets expressions written in our Expr data type:

(eval (Lit 42))                 –- 42
(eval (Div (Lit 44) (Lit 11)))  -- 4

Stripped of real-world concerns, this is very elegant. Now let's add (naive) capability to deal with errors in our interpreter. Instead of the eval function returning integers, we'll return a Try data type, which caters for success (Return) and failure (Err):

data Try a = Err String | Return a

The refactored evalTry function is now much more syntactically noisy with case statements:

evalTry :: Expr -> Try Int
evalTry (Lit a) = Return a
evalTry (Div a b) = case (evalTry a) of
      Err e     -> Err e
      Return a' -> case (evalTry b) of
         Err e  -> Err e
         Return b' -> divTry a' b'

-- helper function
divTry :: Int -> Int -> Try Int
divTry a b = if b == 0
    then Err "Div by Zero"
    else Return (a `div` b)

The reason for the noise is that we have to explicitly propagate errors. If (evalTry a) fails, we return Err and bypass evaluation of the second argument.

We've used the Try data type to make failure more explicit, but it has come at a cost. This is precisely where monads come into play. Let's make our Try data type an instance of Monad:

instance Monad Try where
  return x   = Return x
  fail msg   = Err msg

  Err e    >>= _   = Err e
  Return a >>= f   = f a

Next, we refactor evalTry by using the bind operator (>>=):

evalTry' :: Expr -> Try Int
evalTry' (Lit a)   = Return a
evalTry' (Div a b) = (evalTry' a) >>= a' ->
                       (evalTry' b) >>= ' ->
                         divTry a' b'

-– evalTry' (Div (Lit 44) (Lit 0))

The bind operator enables error propagation:

Err e  >>= _   = Err e

Whenever we encounter an Err, the subsequent argument to the bind operator will be ignored and thereby propagate the error. While this gets rid of our case statements, it is hardly very friendly. Let's rewrite it using the do notation:

evalTry'' (Lit a) = Return a
evalTry'' (Div a b)
  = do
     a' <- (evalTry' a)
     b' <- (evalTry' b)
     divTry a' b'

The Try data type helped us make failure more explicit, while making it an instance of Monad made it easier to work with. In this same way, Monad can be used to make many other "effects" more explicit.

The IO monad is particularly interesting and played an important role in the development of Haskell. When Haskell was first conceived, there were no monads and also no clear solution to the "problem of side effects". In 1989, Eugenio Moggi used monads, from Category theory, to describe programming language features. Phillip Wadler, a then member of the Haskell Committee, recognized that it was possible to express Moggi's ideas in Haskell code:

Because Haskell is a purely functional language, side effects call for special treatment. We will devote a whole chapter to exploring this topic in Chapter 2, Patterns for I/O.