[frogulis]

I like the analogy with musical instruments. Very practical.

I think you're right in saying that async is not representative of all monads, but it does help with questions that many beginners have, like "How do I get the value out of the maybe/IO/your-monad-here?"

[kqr]

I don't think it generalises that well, unfortunately. How to get the value out of Maybe is "just pattern match it". There's nothing process-like about it at all -- it's just a plain container/wrapper.

The async analogy works for some monads like ST and IO and whathaveyou but it's not generally useful, due to the wide variety of types that are monads.

[frogulis]

I think it's still a useful monad to look at. If you just pattern match Maybe, you're not really treating it like a monad or a functor, just as a tagged union that happens to implement a monad interface.

In contrast, there are easily understood reasons to use the monad interface of a promise/async. That's why I think it's a good monad for understanding the structure of monadic binding.

The way I see it is kinda like this, and I hope it makes some sense to others:

You can get the value out of a list... but there might be many or none. You can get the value out of a maybe... if it's there. You can even get the value out of the async function... but you'll just have to hold up what you're doing to wait for it.

This kind of (roughly) non-determinism is how I understand the concept of "effect", which is what Haskell frequently uses monads to model. A function returning a `M a` becomes "deterministic" (it always returns an `M a`) and benefits from the sort of equational reasoning that we like.

To be clear, the use of monads to represent effects is a software engineering decision and not inherent to monads.

It's definitely helped my understanding and I suspect it would help others too.