Its tied to collections, not specifically to List. A number of (but certainly not all!) important monads are (or can be viewed as) collections, including Optional/Maybe (which can be viewed as a collection with cardinality restricted to being either 0 or 1.)
Actually, it transcends collections in general. As others have noted, the term "flatMap" is the concatenation of "flatten" and "map." There are other containers which support flatMap and satisfy the Monad laws[1]. An example of one in Scala is the Future[2] type. It's flatMap is described as:
Creates a new future by applying a function
to the successful result of this future, and
returns the result of the function as the new
future.
1 - http://eed3si9n.com/learning-scalaz/Monad+laws.html
2 - http://www.scala-lang.org/api/2.11.7/#scala.concurrent.Futur...
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.
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.
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.
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.)
What I mean when I say flatMap is tied to collections is in the same sense that I read the poster to whom I was responding when they said it was tied to list, that is, that the intuition that the name "flatMap" leverages is tied to that construct. Obviously, the operation* it describes is more general, but the farther you get from collections, the less useful the intuition that the name leverages is.
(Whether this is better or worse for comprehension than the Haskell style of naming Monads and other related constructs and their associated operations is endlessly debatable and highly subjective.)
It's also impressive how much complexity arise from that notion of multiplicity.
data Fake a = Fake
instance Monad Fake where
return _ = Fake
Fake >>= f = Fake
Its several characters and syllables shorter, and doesn't appeal to an intuition which is distant from many of the productive uses of construct.
The same concepts apply. With an option type, flatMap can be defined in Scala Option[1] types as:
flatMap[B](f: (A) ⇒ Option[B]): Option[B]
What makes Monads neat IMHO is that so long as the container type adheres to the Monad laws[2], then the developer can fully rely on the behaviour conforming to a common set of expectations.
This seems to be the approach that Elm is taking. (Although they're reluctant to add monads at all since they take ease of use seriously.)
Instead we get nice "English" names which only work for certain monad instances and fail to adequately describe others.
Elm uses "andThen" instead of "bind", which works pretty well for the monadic types in its core library. But you need to start stretching your imagination to see why "andThen" makes sense for other monadic types. Honestly, I'm fine with "andThen", especially in the context of Elm and the monads it implicitly uses. But in the wider world of programming where exotic but useful monad instances exist I'd rather stick to the most general name.
By the way, the more pressing reason for Elm not having monads is the fact that it doesn't have typeclasses (or a similar concept) and doesn't allow you to parametrize over higher-kinded types (like Maybe).
Perhaps "then" would work. JavaScript promises use it to good effect, and they're a monad.
(BTW, my own take on renaming a monad into something less scary is daisychain, or, slightly more to-the-point, chainable.)
I'm not convinced English has a word or convenient phrase for "monad", and it doesn't strike me that "flatMap" is it. How do I "flatMap" Haskell's STM monad? Or a probability monad? (I know the mechanics of the answer, I am specifically referring to the English-induced intution.) I don't see the intuition being particularly correct; flatMap is really tied to List, which isn't a particularly great thing to be tied to since it isn't very used. List's monadic interface is cute for some little algorithms, sure, which makes it disproportionately appear in examples, but list's monad implementation has complexity O(m^n) (where m is the size of the lists and n the number of lists you're going to consider) and you need some algorithm that gives you some serious culling on that before it's practical for very much.