Hacker News Reader

Comment by jerf | Hacker News Reader

Honest question: Is there a reason 'flatmap' is any better other than it is what you learned it as somewhere?

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.

View on HN

> flatMap is really tied to List

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

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

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

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

"Compose" being Kleisli composition?

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

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

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

Parsers is an obvious example.

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.

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.

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.

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

That's true. The concept of "flatmapping" an array is easy to get, but what about flatmapping and optional/maybe value?

> ... what about flatmapping and optional/maybe value?

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]

For the empty option situation (None in Scala), the result is a None. For the populated case (Some in Scala), the result is what f produces when given the value contained in the original Option[A] type. Of course, f is free to produce a None for its result should it so desire.

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.

1 - http://www.scala-lang.org/api/2.11.7/#scala.Option

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

I think the parent was saying that "flatMap" failed to give them intuition around Option, not that Option wasn't a monad.

It certainly doesn't have to be flatmap. But the idea is that someone takes some time to think up an English name and does a bit of user testing to make sense to regular programmers.

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

What's wrong with 'bind' ?

What's being bound?

Perhaps "then" would work. JavaScript promises use it to good effect, and they're a monad.

Smaller computations are being bound into a larger computation, where the monad provides the the code that is executed 'between the lines'.

(BTW, my own take on renaming a monad into something less scary is daisychain, or, slightly more to-the-point, chainable.)

    (>>=) :: M a -> (a -> M b) -> M b

The `a` is bound in the second argument.

We all know that naming is one of the hard problems in computer science. Monads in programming have been around for 20+ years now, and you are certainly not the first one to complain about their name. So where are the better alternatives? Surely someone must have come up with a better one by now?

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

Reply on news.ycombinator.com