Well that's just it, though. The proper way of generalizing your notion of mapping is Functor and your notion of flattening is Monad. So the intuition behind the word has bought nothing.
> The proper way of generalizing your notion of mapping is Functor and your notion of flattening is Monad.
You are quite right that the "map part" of flatMap is Functor, as Monads are a model of Functor. IOW, if there exists a Monad for some container, then there also exists a Functor for it.
However, flattening in and of itself does not fully define the flatMap (a.k.a. "bind") part of a Monad. Its atomic use with the map operation is what makes flatMap/bind operations satisfy the expectations of the rules for being a Monad.
Flatten on its own is extremely useful of course. It's often used in definitions of Join type classes.
It does given a Functor definition. Typically in Category Theoretic presentations Monad is defined as a functor T along with mu and nu, operations that are (a -> T a) and (T (T a) -> T a), 'unit' and 'join'.
The rules for Monad are perfectly well-stated in terms of join—perhaps even better stated if you're one to like Category Theoretic diagram chasing.
Again, you are quite right. I did not present the other ways to define a conforming Monad and may have mistakenly implied that the unit/flatMap form is "the" way to make one.
For completeness, the forms I am aware of are (in no particular order):
* unit and flatMap
* unit and compose
* unit, map, and join
The valid form which you reference being a model of the last one.
AFAIK, for any container 'T' to be able to satisfy the Monad laws, at least one of the aforementioned three combinators must exist for the container.
> AFAIK, for any container 'T' to be able to satisfy the Monad laws, at least one of the aforementioned three combinators must exist for the container.
All three of them must, actually, since if one of them exists, all of them do (and you can define the other two in terms of the one you know.)
