> I don't know why people try to explain monads without explaining this first<p>I mean, I get where you're coming from, but the thing that you've described is that a monad and there's not an easy way to get it there.<p>But yes, I am with you, you want to explain to someone that Haskell's model of side effects is a sort of <i>metaprogramming</i>, much simpler than macros, we just give you a data type for “a program which does some stuff and eventually can produce a ______” and ask you to define a value called `main` which is a program which produces nothing special. And it's the compiler's job to take that program and give it to you as a binary executable that you can run whenever you like.<p>You also want to give people a number of other examples of things that are monads. “a nullable ____”, “a list of ____s,” “an int (summable) with a ____,” and maybe an example that is not like “a
function from ____s to ints,” or “a set of ___s.”<p>The key to telling someone what a monad is, involves trying to explain to them that in some sense “a program which produces a program which produces an int” is not terribly more descriptive than just “a program which produces an int.” If you can combine this with the adjective being outputtish and universal you have a monad.