Tony Morris

All monads are also functors (things that can be mapped) and applicative functors (which allow mapping "multi-arg" functions across multiple values). Monad is a sub-class of functor and applicative. Monad gives you more power, but there are fewer things that are monads.

The extra power of monad is the ability to decide what to do "next" based on intermediate results. As a concrete example, consider parsing a data type with tagged fields or run-length encoding. You need to see the parse of the first part to decide how to parse the next part.

Some languages/libraries call this capability "bind". "andThen" is also common. In Haskell it is an infix function '(>>=)' but we pronounce it "bind".

In a made-up language bind looks like: typeclass Monad k where (Applicative k): bind(inVal : k a, func : a → k b) → k b It takes monadic 'inVal' which contains/ produces values of type 'a', applies 'func' to the 'a's and returns 'k b' (same monad 'k'; inner type can change)

Setting 'k' as 'List', bind has the form: bind(inVal : List a, func : a → List b) → List b What does this do? There is only one (lawful) possibility. It maps 'func' across 'inVal' to give a 'List (List b)', and then it flattens the list. bind for List is "flatMap"!

I keep mentioning "laws". Here are the laws for monad: bind(pure(a), f) = f(a) bind(m, pure) = m bind(m, lambda x: bind(f(x), g)) = bind(bind(m, f), g) 'pure' is explained in the next tweet.

'pure' comes from applicative and has the type 'a → k a' where 'k' is any applicative functor. 'pure' "lifts" a pure value into the context 'k'. For List, 'pure' returns a single-element list. For this discussion, the main reason to care about 'pure' is that the laws use it.

For me personally, the critical intuition for monad is that if you need to see "intermediate results" to continue a computation, you need monad. Monad is the weakest abstraction that gives you that power.