> Its tied to collections, not specifically to List

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.

Conceptually, this behaves similarly to how a flatMap for a collection type behaves. Due to the nature of the Monad laws[1], this similarity is to be expected.

1 - http://eed3si9n.com/learning-scalaz/Monad+laws.html

2 - http://www.scala-lang.org/api/2.11.7/#scala.concurrent.Futur...

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.)

"Compose" being Kleisli composition?

> Actually, it transcends collections in general.

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.)

Gotcha. In reading the post to which you originally replied, it appeared to me that there was an underlying assumption of Monads being specific to collections. My bad.

Interesting quantification of Option. Mapping Boolean logic to binary arithmetic somehow ?

It's also impressive how much complexity arise from that notion of multiplicity.

Follow-on question, are there any useful monadic constructs not tied to collections (including optional as you said)?

IO, State, Parsers, and STM are useful monads for which the collection metaphor doesn't seem to be particularly helpful.

STM's a good one. I'd consider I/O and State as solving a self-inflicted problem -- I can have side-effect-creating I/O and State in just plain C with barely any type system.

Is Maybe tied to collections? State? Reader? Cont? What about Eff from extensible-effects? I use these every day.

As mentioned elsewhere here, Maybe is naturally considered a container of zero-or-one elements. The others are good examples, though.

Parsers is an obvious example.

Future, Either, Writer, and Free are the non-collection ones I use most often.

Silly and wonderful there is always

    data Fake a = Fake

which is trivially a monad

    instance Monad Fake where
      return _ = Fake
      Fake >>= f = Fake

yet it clearly contains nothing.

Grandparent asked for useful though :P

Who says Fake isn't useful? It's very useful for stating that nothing can happen :)

Futures are another example.

I'd call a Future a threadsafe queue with one element going thru it IMO, it's just as much of a collection as Optional.

That's the beautiful thing about types which satisfy the Monad laws. Because both Future and Option (in Scala if not other languages) satisfy these laws, I think it perfectly valid to consider a Future to be collection type with a cardinality of 0 or 1 that also abstracts latency.

Yeah, but I can do that without category theory, it's just obvious. I still don't understand what 'monad' offers over 'flatMappable' besides the ability to use 'endofunctor' in the same sentence.

> I still don't understand what 'monad' offers over 'flatMappable'

Its several characters and syllables shorter, and doesn't appeal to an intuition which is distant from many of the productive uses of construct.