4 ms·

> Its tied to collections, not specifically to List Actually, it transcends collections in general. As others have noted, the term "flatMap" is the concatenat

> 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 http://eed3si9n.com/learning-scalaz/Monad+laws.html 2 - http://www.scala-lang.org/api/2.11.7/#scala.concurrent.Future http://www.scala-lang.org/api/2.11.7/#scala.concurrent.Futur...

tel 11y ago
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.
- AdieuToLogic 11y ago
  > 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.
  - tel 11y ago
    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.
    - AdieuToLogic 11y ago
      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.
      - dllthomas 11y ago
        "Compose" being Kleisli composition?
      - dragonwriter 11y ago
        > 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.)
dragonwriter 11y ago
> 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.)
- AdieuToLogic 11y ago
  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.

tel 11y ago

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.

AdieuToLogic 11y ago
> 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.
- tel 11y ago
  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.
  - AdieuToLogic 11y ago
    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.
    - dllthomas 11y ago
      "Compose" being Kleisli composition?
    - dragonwriter 11y ago
      > 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.)

dragonwriter 11y ago

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

AdieuToLogic 11y ago
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.