Functors, Applicatives, and Monads in Pictures (2013)

Functors, Applicatives, and Monads in Pictures (2013)
adit.io

The core useful operator for monads in Haskell is >>=. It has the following type:

    m a -> (a -> m b) -> m b

    a -> (a -> b) -> b

For example, take the Maybe type. It's Haskell's nullable: a Maybe a means you either have an a or Nothing.

    data Maybe a = Just a | Nothing

    (>>=) :: Maybe a -> (a -> Maybe b) -> Maybe b
    x >>= f = ...

    Nothing >>= f = Nothing
    Just x  >>= f = f x

For Maybe, being a monad gives us a standard way of working with values while automatically dealing with Nothing. It abstracts over repetitive null checking and lets us easily build up Maybe values based on other Maybe values.

Other examples of monads are the same in spirit. The list monad, for example, lets us handle any number of inputs in a way that's similar to Maybe. The State monad similarly lets us combine values while carrying along an implicit state internally.

The rest of the Monad structure (namely the return function and the laws) are just a formal way of codifying behavior behavior that's already intuitive.

So how does this all apply to doing input and output?

Well, the problem in Haskell is that it's a language of evaluating expressions at heart: executing effects makes no sense any more than it would in arithmetic. To work with effects we instead have a special, opaque type IO; normal expressions get evaluated to IO actions that can be run to produce the desired effect—namely the IO type.

Critically, the IO type does not have to be a monad. It could be completely self-contained and have custom functions for doing one action after the other. We could imagine something like:

    after :: IO a -> IO b -> IO b

However, we would also like some way of using the results of an IO statement, perhaps assigning them to a name. We can't do this normally because the IO statements are run separately from expression evaluation. We'd have to have some sort of function that could take an IO value, unwrap it and do something with it. And how would we express an interface like this? With a normal function!

    doSomething :: IO a -> (a -> IO b) -> IO b

I'm hand-waving a bit again, but the rest of the monad structure comes up when you try to make sure after behaves consistently and intuitively.

So IO being a monad emerges naturally from the desire to be able to compose actions and depend on their results in a way that's separate from normal variable bindings and expression evaluation.

The causation here is important: it's not that IO is a monad, but rather the IO type (which could exist on its own) happens to naturally and usefully form a monad. But it does a lot of other things too, including some specific capabilities (like spawning threads) that are hard to generalize.

So my point, I suppose, is twofold: monads are useful for combining some notion of computation and IO happens to be an interesting example, but the fact that we wrap statements with external effects in a custom type called IO does not inextricably depend on the idea of a monad.

Did that explanation help? I wrote a blog post on a similar topic that might be interesting too: http://jelv.is/blog/Haskell-Monads-and-Purity

So I think that expanding your idea of what monads do might help. Monads enforce a sequencing, and let later computations in the sequence depend on the result of an earlier one. Have a look at the definition of the Monad instance for Maybe:

    instance  Monad Maybe  where
        return x            = Just x
        (Just x) >>= k      = k x
        Nothing  >>= _      = Nothing

    case lookup myMap "a" of
      Nothing -> Nothing
      Just v -> case lookup myMap v of
                  Nothing -> Nothing
                  Just v' -> lookup myMap v'

    do
      v