[ilikebits]

Monads are a generalization of Promises. Each type in Monad defines their own `.then` in a different way. For promises, `.then` is defined as "run this function once you have this deferred value from the last promise". For optionals (`Maybe`), `.then` is defined as "run this function if the last optional had an actual value". For Either, `.then` is defined as "run this function if the last Either returned Right, otherwise early-return with the value from Left" (this is functional early-return, basically).

[bhaney]

This is the first explanation of monads I've heard that makes intuitive sense to me and feels like it sufficiently captures the point. Unless I come back in a few hours to see a bunch of replies from uber-haskellers saying "no that's not what a monad is at all," then I'll consider my search for a good monad explanation to finally be over.

[tickettotranai]

No I believe he's basically formally correct.

You need to be able to "wrap" values and then also "wrap" functions in the way you expect. That's literally it.

Btw, the list monad example is stupid imo and borderline misleading. The promise/nullable/Either examples are better. you "wrap" a function by putting it as the only value in a list, and "map" pretty much acts as your function wrapper, but technically this you need to jump through a couple hoops to make it monadic, and I'm just not sure the metaphor is helpful here

[dllthomas]

For some monads the "wrap" gets awfully metaphorical (for State it's a function that produces the value and updated state, for Const there is no value, etc) but I don't think that's actually a problem, just a thing to be aware of. There is certainly no expectation that you can actually get your hands on the thing.

A bigger issue is that you're missing a piece. If you can "wrap" values and "wrap" functions such that they operate on wrapped values, you (probably) have a functor. To be a monad you also need to have the ability to turn multiple layers of wrapping into one layer of wrapping. For lists, that's "flatten".

I said "probably" above because there are rules these pieces need to follow to behave well. They're pretty simple but I don't think we need to dig into them at this level of discussion.

[internet_points]

Agree about the list monad. I have never used it in actual code. I always felt it was so arbitrary, and "implicit", in the sense that if you haven't learnt beforehand that it makes "joins", then it's certainly not obvious that it should work that way

    λ> do { a <- [1,2]; pure a; }
    [1,2]
    -- oh so it returns the list unchanged
    λ> do { a <- [1,2]; b <- [3,4]; pure a; }
    [1,1,2,2]
    -- no what is this spooky action at a distance
    λ> do { a <- [1,2]; b <- [3,4]; pure [a]; }
    [[1],[1],[2],[2]]
    -- ...
    λ> do { a <- [1,2]; b <- [3,4]; c <- []; pure [a]; }
    []
    λ> do { a <- [1,2]; b <- [3,4]; c <- [5]; pure [a,b,c]; }
    [[1,3,5],[1,4,5],[2,3,5],[2,4,5]]

[binary132]

This is misleading IMO because Promise is a particular kind of monad but in general monads don’t necessarily have anything to do with asynchrony. It is a useful example though because some people are more familiar with the API of promises.

I might have some inaccuracies in how I state this since I’m not from a functional programming background, but I think of monads as an abstraction of chaining functions over a value such that each returned value can specify what further transformations it supports, and particularly in such a way that generic transformations (like sequence reversal) can easily be applied, and errors or empty values can be accounted for within the control flow.

I think sometimes people call this a “fluent API”, but I would never call it “a generalization of callbacks” or of promises.

Anyway there’s a much more mathematically precise way of stating it but this is my intuitive caveman way of thinking about it.

[tasuki]

Promises? Even more generally, Monads are a generalization of Chaining.

(I'm trying very hard not to fall into the trying-to-explain-monads trap!)