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.