Monads explained by Eric Lippert

Monads explained by Eric Lippert
ericlippert.com

Technical people can't go straight to the point. They go around, around, around, going into corners, etc

(not only on explanations, mind you)

For example, math has some very high-level/generic explanations, and curiously, I find them more understandable.

So, I've given up on understanding Monads (or at least Haskell ones), I'll probably understand them when I come up with a similar problem and think about how to solve them.

1) There is a category theoretical concept of a monad. This is largely irrelevant in a practical explanation of monads since Monads are usually talked about in terms of another category theoretical concept called the Kleisli Category or Kleisli Triple. However, if someone starts talking about "monad laws", they're probably referring to the theoretical sense of this.

2) There is, in Haskell at any rate, a typeclass called the Monad (note the capital "M"). This is mostly important because when a type is an instance of this category, the Haskell do-notation is useful. Aside from that, you can only use the handful of operations that the Monad typeclass implements that you don't have to implement yourself for it to be an instance of Monad.

3) There are Monad type constructors, such as Maybe, IO, and State. This is where things actually start getting interesting for the practitioner, because each provides a specific abstraction of a concept, such as input/output or partial functions (IO and Maybe, respectively).

4) There are Monad types, both abstract and concrete, like Maybe a, IO a, Maybe Int, State MyType and so on. These are the types you actually will program with.

5) There are Monad values, which are instances of the Monad types, which are, themselves, instances of the Monad type constructors, which are instances of the Monad typeclass.

6) Then just to add a slightly extra confusing layer on top of it all, you have the values inside the Monad you'll actually be doing computations with.

7) And finally, it doesn't help when in code examples, type variables and function variables are conflated by name, such as in:

    get :: State s s
    get s = (s,s)

So, yeah. Simple concept of explicit effects. Seriously semantically overloaded stack of terms to actual reason with them about.