The “What Are Monads?” Fallacy

> You can even see it in code examples where it is pretty common to see arbitrary one-letter variable names.

This is usually because Haskell functions are really short. For example:

    compose f g x = f (g x)

We could write this with more descriptive variable names, but there are only 3 variables and they're only in scope for one very tiny line:

    compose outerFunction innerFunction argumentForInnerFunction = outerFunction (innerFunction argumentForInnerFunction)

There are certain conventions as well; if a variable must be present, but isn't used, it gets called `_`:

    first (x, _) = x

Lists tend to get a plural "s" on their name:

    elem x xs = any (map (x ==) xs)

> So when the Haskell people try to explain monads, they start with the abstract definition, the monadic laws and so on, and they focus on explaining the concept of a monad, rather than what they are practially useful for. For the typical developer this might seem like a lot of mathematical wanking for little benefit.

This is because functional programmers tends to spend the most time on writing generic, abstract, re-usable libraries. Particular applications are just thin veneers on top of these libraries. For example, I might spend most of my time writing generic, abstract code to deal with tuples. To make an application, I can just pick and choose the library code I want to use:

    type Name = String
    type Address = String
    type Quantity = Int
    type OrderID = Int
    type SKU = Int
    type Customer = Tuple Name Address
    type Order = [Tuple SKU Quantity]
    type Invoice = Tuple Customer Order

Given that I'm using Tuples for Orders, Invoices and Customers, the time I spent writing abstract code to deal with tuples wasn't "a lot of mathematical wanking for little benefit".

The time spent writing generic, abstract monad libraries isn't wasted either; by picking and choosing which monads to use, our application can automatically get error-handing, non-determinism, backtracking, exceptions, state, software transactional memory, etc.

While computation expressions indeed appear to capture the concept of do notation, as far as I know, F# lacks the machinery (higher kinded polymorphism) to be able to express the abstract monadic concept (though it can obviously express specific monads, just like most modern languages). So I'm not sure it's a very good example of how much more "pragmatic" F# culture is so much as it is an example of a feature F# doesn't actually have.

The mother of all monads is the continuation monad. That's the most canonical monads that can implement all other monads. It's rather too abstract as an example to beginners, though.

The thing that makes monads so powerful is they can be used in a such a wide variety of situations. You can model control flow with the continuation monad, concurrency with the future monad, and error handling with the either monad. Three very different domains but only one abstraction to learn!

I can also give you a very succinct definition of a monad, or a succinct example, but I doubt you'd understand them until you've seen many examples in different domains.

(If you want examples or defn, there are many web pages that have them.)

There are a large number of canonical, succinct examples of monads. Are you interested in use or definition?

There are clearly a bunch of examples of monads that are even pretty understandable in contexts that aren't Haskel (Maybe and Either, as this blog post points out, are succinct examples). It's multiple concepts under the same banner in the same way that 'the visitor pattern' can represent a whole bunch of actual tasks, but the way you perform them is similar enough to justify a name for it.

Really the problem, alluded to in the blog post, is that the worst thing you can possibly do to 'explain' monads is to try to remove them from their context. They aren't fruit, they aren't tupperwear, and a bunch of the incarnations of them aren't useful in imperative programming, so trying to explain them in those contexts is futile.

I'd say Monads shouldn't require the use of Haskell to be understood.

I personally don't understand them.Some people told me it's a bit like "reversed" generics,some others pointed me at promises in Javascript which are "monadic".

I guess I don't understand them because I work with languages that make them either hard to implement or totally unnecessary.

Each monads have its own semantics, so yes, they are multiple concepts. The Maybe-monad is used to solve totally different problems than the IO-monad. Also things like list comprenhensions is implemented as a monad in Haskell.

I found this to be a great practical introduction to monads: http://codon.com/refactoring-ruby-with-monads. It holds your hand the whole way, so it gets a bit long and tedious, but it's great at showing how three different common monads can clean up similar looking code in similar ways. I'm sure the Haskell purists out there can find 20+ different things wrong with it, or will scoff at how it's in Ruby, etc., but if you ask me those are tiny prices to pay in an introductory context for how pragmatic, explicit, and helpful it is.

There are lots of simple succinct examples of monads, for example Option types and Promises. The point is that monad is more like a design pattern than a 'thing'. This means that it's precisely true that it can cover multiple concepts, but that's a good thing, it's where it gets its value and power from. It provides common patterns of interaction that are applicable in a surprisingly wide range of situations.

I'd say you're right, but it's the extra stuff that Haskell associates with monads that make them hard to learn. Here's how I'd break it down:

1. The three Monad laws, which have been beaten to death.

2. do-notation. You've started to learn Haskell, and you know the let-in syntax for introducing variable bindings, and suddenly you get hit with two NEW syntaxes: the let-but-no-in syntax, and the weird <- stuff. How do these syntaxes relate, and why (if?) are they all necessary? Also you just lost fifteen minutes because that line has a tab instead of spaces, the "last statement must be an expression" nonsense, etc.

3. Monadic APIs, especially IO. You can go through an entire Monad tutorial and be left wondering why you need category theory to get main's argv. Not to mention all of the duplication (mapM, filterM, zipWithM, etc).

Tutorials tend to focus on #1, but in my journey I found #2 and #3 to give me the most difficulty.

Imagine a concept called "Additive". Any type that defines a '+' operator is "Additive".

In most industrial languages, integers, floats and strings are Additive, because these things support the '+' operator.

Monads are at the same level of "concept" as Additive. Something is a monad if it has a set of operators that map to the Monad concept. The level of abstraction you need to be at, mentally, is "supports a specific set of operations with specific rules". A lot like an interface, but at the type level.

It is definitely a single concept, but there are variations on it, like Functor and Applicative, which are related. The core concept is adding a layer of indirection between a value and application of a function to the value. What the indirection does is the chief distinguishing feature of the monad. A Maybe monad only applies the function if the value is not None, for example. A List monad applies the function to each value in the list. The IO monad, on the other hand, logically stores the function and keeps it for later - the result of computing a pure functional Haskell program returning IO is an imperative program, which is then executed. That's how Haskell gets its side-effects in a pure fashion.

A monad is any pair of functions (usually called `bind`/`>>=` and `return`) that fulfills the three monad laws:

    1. bind(return(a), f) = f(a)
    2. bind(m, return) = m
    3. bind(bind(m, f), g) = bind(m, x -> bind(f(x), g))

That's all. Any pair of functions with those properties is a monad.

So, for an interesting example of using monads, consider parser combinators. I'm basing this loosely off of the parsers provided by the parsec package, but simplifying a bit.

Let the type "Parser a" represent a parser that produces an "a", after consuming some (or no) input.

(In Haskell, lowercase letters are used for polymorphic types; Parser Integer is a parser that produces an Integer, Parser String a parser that produces a string, and so on. Any concrete value will be of some more specialized type, but functions can work on the polymorphic version if they don't rely on it being something more specific.)

Note that parsers may also fail, and give up on parsing further input, instead returning information about how it failed.

To run a parser against some input, we can do something like:

    case (parse someParser inputString) of
        ResultFailure errorString -> do something with error string
        ResultSuccess value -> do something with value

where

    parse :: Parser a -> String -> Result a

    data Result a = ResultFailure String | ResultSuccess a

We can put together a lot of things of this type. The simplest returns just a fixed thing and doesn't even look at the input.

    return :: a -> Parser a

So the expression,

    parse (return 5) inputString

would reduce to ResultSuccess 5, regardless of the input.

We can also have things that return the next character, whatever it is:

    anyChar :: Parser Char

    parse anyChar "f" -- ResultSuccess 'f'
    parse anyChar "7" -- ResultSuccess '7'
    parse anyChar "" -- ResultFailure "premature end of input"

Or we can have something more restricted, like...

    oneOf :: [Char] -> Parser Char

    abc = oneOf ['a', 'b', 'c']

    parse abc "a" -- ResultSuccess 'a'
    parse abc "d" -- ResultFailure "unexpected 'd'"

And we can have more sophisticated things:

    natural :: Parser Integer

So now... where does "monad" come in?

Well, when we go to build a new parser out of these components, we need some way of combining them. We can do our parsing explicitly...

    parseWithLeftovers :: Parser a -> String -> (String, Result a)

    parseTwoIntegers input = case parseWithLeftovers integer input of
        (_, ResultFailure errorString) -> ...

        (input2, ResultSuccess int1) -> case parseWithLeftovers whiteSpace input2 of
            (_, ResultFailure errorString) -> ...

            (input3, ResultSuccess _) -> case parseWithLeftovers integer input3 of
                (_, ResultFailure errorString) -> ...
                (_, ResultSuccess int2) -> return (int, int2)

It should be plenty obvious why we don't want to do that every time. Let's factor out the boiler plate. The question is what that looks like...

What if we set it up so those results could be collected and passed to an arbitrary function? That could let us write something like...

    parseTwoIntegers = (,) <$> integer <*> (whiteSpace *> integer)

While you may not understand the symbols, I expect you'll agree that's quite a bit more readable.

But that still doesn't actually require monads. <$> is a synonym for fmap, the two operators containing asterisks are from Applicative. Can we do everything we might want with these, without getting crazy explicit and chaining parsers by hand again?

Well, let's look a little closer at what's going on above. Specialized for clarity, the above operators have the following types:

    (,) :: a -> b -> (a, b)

        tuple operator - takes two arguments, makes a tuple out of them


    (<$>) :: (a -> b) -> Parser a -> Parser b

        "fmap" - applies a function to the result of a
            parser, making it into a parser that does the
            same thing but returns the modified result

    (<*>) :: Parser (a -> b) -> Parser a -> Parser b

        "ap" - takes a parser *producing a function*, and a
            parser producing a value, and gives us a parser
            that applies the function to the value

    (*>) :: Parser a -> Parser b -> Parser b

        Takes two parsers, runs both, returns the result of the second

Walking the above expression from left to right, we see...

    (,)                 :: a -> b -> (a, b) -- tuple operator


    (,) <$>             :: Parser a -> Parser (b -> (a, b))
        note that the partial application of (,) *inside* 
        the parser gives us a parser returning a function


    (,) <$> integer     :: Parser (b -> (Integer, b))
        we've picked our "a" and are left with a parser
        returning a function - a job for "ap"


    (,) <$> integer <*> :: Parser b -> Parser (Integer, b)
        It should be reasonably apparent how the bit in
        parens reduces, so skipping ahead...


    (,) <$> integer <*> (whiteSpace *> integer) :: Parser (Integer, Integer)

It's easier - and not wrong - to think of "f <$> ... <> ... <> ..." as "apply this function to these wrapped values, giving me a wrapped result" - but the above is how that happens, and following it is a bit necessary for this next bit...

What if we want to write

    readNChars :: Parser [Char]

where the parser first reads the number of characters to read, and then reads that number of characters?

Looking at the above operators, there's something that the function arguments (wrapped or not) have in common: none of the function arguments return a Parser. So the functions can't dictate what is parsed. That's what we fix next:

    (>>=) :: Parser a -> (a -> Parser b) -> Parser b
        "bind" - takes a parser, and a function that 
        returns a parser, runs the first parser, feeds the 
        result into the function, and runs the resulting
        parser

This, then, allows us to say things like:

     parseCountItems :: Parser a -> Integer -> Parser [a]
     parseCountItems p i = sequence (genericReplicate i p)

     readNChars :: Parser [Char]
     readNChars = integer >>= parseCountItems anyChar

Haskell programmers care that it's a monad for three reasons. First, communicative value - the pattern comes up a lot and it's useful to be able to quickly convey what's going on. Second, there are actually a number of useful functions that can be applied to any monad. For instance,

    mapM :: Monad m => (a -> m b) -> [a] -> m [b]
    filterM :: Monad m => (a -> m Bool) -> [a] -> m [a]
    when :: Monad m => Bool -> m () -> m ()
    foldM :: Monad m => (a -> b -> m a) -> a -> [b] -> m a

Finally, do notation. Haskell provides some syntactic sugar that turns

    do
        statement1
        var <- statement2
        statement3 var

into

    statement1 >>= \ _ -> statement2 >>= \ var -> statement3 var

The above "readNChars" could be rewritten:

    readNChars = do
        cnt <- integer
        sequence (genericReplicate cnt anyChar)

Do notation can often be clearer for complicated monadic expressions.

The 'The "What are Monads?" Fallacy' Fallacy?

A monad is just a code pattern. If you try to program in a style that minimises mutate state you'll probably end up inventing something like a monad. Heck, jQuery is almost a monad -- it's not a true monad but it is similar in concept.

Monads are not a big deal. Indeed they are so much of a not big deal that I expect this is a big part of the problem learning monads. People expect them to be something difficult and exotic, and go looking for hidden depths where there aren't any. I know I did when I first learned them. Eventually you break through and realise there is no hidden mystery. It's just a data type with a few functions, and they happen to be usable in a wide variety of contexts. That's what this blog post is trying to explain.

Finally, you can teach monads to new hires in a very short period of time. We do in our training courses.