3 ms·

So bind is flat map in other languages? If join is a function that take a list and appends its elements together join ( [[1], [2], [3]] ) -> [1,2,3] then bind

So bind is flat map in other languages? If join is a function that take a list and appends its elements together join ( [[1], [2], [3]] ) -> [1,2,3] then bind is join(map(f, x))? bind just seems like a terrible name. For some reason Haskell users try to make things sounds as academic as possible.

gizmo686 10y ago
>For some reason Haskell users try to make things sounds as academic as possible. Probably because Haskell ended up being the language for academics. If you want to do programming language research in an ML-type language use Haskell. If you want to make a product, use OCaml. Not entirely true, but pretty close. >So bind is flat map in other languages. In the case of a List, yes, but there are other datastructures that implement Monad. This type of thing happens a fair amount in Haskell. It is not that uncommon to see code like: instance Monad List where (>>=) = flatMap That is to say, the implementation of the interface is just another function that has a more domain specific name. There are other monads with a bind that cannot be understood as flatMap. For example, the Maybe datatype is Haskell's version of Optional. For example, if a variable is of type `Maybe t`, it either contains a single value of type t, or no value. It is common to use Maybe without using it as a monad. However, Maybe does implement the Monad interface. In this case, bind is defined as follows: x.bind(f) = if (x.hasValue()) then { return Just(f(x.value)) } else { return Nothing() } where Just and Nothing are two constructors of Maybe. If we view 'no value' as analogous to null, then this bind function is null propogation.
- Forlien 10y ago
  I feel a bit dumb asking this, but your explanation doesn't make it clear to me why you can't think of a bind on Maybe as a flatMap on a List with 0 (Nothing) or 1 (Just) elements. Could you elaborate further on how thinking of a bind on Maybe as null propagation eliminates it also being interpreted as a flatMap on a restricted-size list?
  - fmap 10y ago
    You're right, maybe is equivalent to the type of lists with at most one element. There are however monad instances which are genuinely different. For example the state monad is defined as F(X) = S -> S*X I.e., a value of type F(X) is a state transformer which takes a state argument of type S and produces the new state and a value of type X. In this case, bind is sequencing of state transformers. Using the state monad you can write code that looks like it uses a global variable of type S, while being completely pure which makes testing and refactoring easier, and of course doesn't pollute the rest of the program.
  - acomar 10y ago
    Unfortunately, not all monads are list-like (though there are a lot that are). The most notorious example is probably Cont[1], the monad of delimited continuations. State, ST, and IO all struggle to be interpreted as lists as well. [1]: http://blog.sigfpe.com/2008/12/mother-of-all-monads.html http://blog.sigfpe.com/2008/12/mother-of-all-monads.html
tomsmeding 10y ago
Bind is flatmap in the case of lists. Bind is way more generic than just the list monad, and the name "flatmap" doesn't apply to most other monads -- most of which are not List.
aninhumer 10y ago
Yes, bind is just flatMap. Various people seem to be arguing that "flatMap" only makes sense for Lists and similar containers, but I don't really see why. Yes, you have to broaden your notion of "flattening" to understand it, but I think that's a lot easier for people to learn than a "new" operation called "bind". I've been using Scala for a while after learning Haskell first (and understanding monads), and I've noticed how much more easily people understand flatMap, even for e.g. Futures.
- chousuke 10y ago
  Maybe it's just a difference of perspective, but I do not understand what is so intuitive about flatMap that makes it "easier". The name does not fully capture the idea of bind and requires mental gymnastics to apply to less concrete usecases, whereas bind is not so restricting, while still referring to the use of the abstraction as "glue" and hinting at its relation to composition.
  - aninhumer 10y ago
    I think the thing that makes it more intuitive is that it's really easy to see how "flatMap" relates to "flatten" and "map", whereas it's not immediately obvious how "bind" relates to "join" and "map". And I think expanding a concept which someone already comfortably understands is a lot easier than asking them to learn a new one, even if you say it's kind of similar. And FWIW, I don't think "flatten" is particularly unintuitive name, even for the more abstract cases, because it's still f (f a) -> f a. The mental gymnastics here is understanding how a Functor can be more than just a container, and you kind of need to learn that anyway.
imh 10y ago
Bind is a great name. When you have a function that takes a monadic value of type `m a` (e.g. List[A_] in scala I think) it becomes convenient to program with lambda functions. For list comprehension, you can program like this (python notation now, since everyone reads it): bind(list_of_xs, lambda x: bind(list_of_ys, lambda y: return(x+y))) That's a list comprehension. You bind the monadic values (list_of_xs) to element values (x). On lines 2 and 3, you can think of x as a bound variable that was assigned to one of the elements of list_of_xs on line 1. Then we "assign" y on line 2, and it's in scope on line 3. "Assign" would have also been a decent name for it. It's way more intuitive for me to think of those three lines as assigning/binding x and y to be summed together, rather than thinking of one flatmap of a lambda to flatmap of a final lambda to a function. The abstraction of variable binding just fits.
- jnordwick 10y ago
  This isn't even close to being clear.

gizmo686 10y ago

>For some reason Haskell users try to make things sounds as academic as possible. Probably because Haskell ended up being the language for academics. If you want to do programming language research in an ML-type language use Haskell. If you want to make a product, use OCaml. Not entirely true, but pretty close. >So bind is flat map in other languages. In the case of a List, yes, but there are other datastructures that implement Monad. This type of thing happens a fair amount in Haskell. It is not that uncommon to see code like: instance Monad List where (>>=) = flatMap That is to say, the implementation of the interface is just another function that has a more domain specific name. There are other monads with a bind that cannot be understood as flatMap. For example, the Maybe datatype is Haskell's version of Optional. For example, if a variable is of type `Maybe t`, it either contains a single value of type t, or no value. It is common to use Maybe without using it as a monad. However, Maybe does implement the Monad interface. In this case, bind is defined as follows: x.bind(f) = if (x.hasValue()) then { return Just(f(x.value)) } else { return Nothing() } where Just and Nothing are two constructors of Maybe. If we view 'no value' as analogous to null, then this bind function is null propogation.

Forlien 10y ago
I feel a bit dumb asking this, but your explanation doesn't make it clear to me why you can't think of a bind on Maybe as a flatMap on a List with 0 (Nothing) or 1 (Just) elements. Could you elaborate further on how thinking of a bind on Maybe as null propagation eliminates it also being interpreted as a flatMap on a restricted-size list?
- fmap 10y ago
  You're right, maybe is equivalent to the type of lists with at most one element. There are however monad instances which are genuinely different. For example the state monad is defined as F(X) = S -> S*X I.e., a value of type F(X) is a state transformer which takes a state argument of type S and produces the new state and a value of type X. In this case, bind is sequencing of state transformers. Using the state monad you can write code that looks like it uses a global variable of type S, while being completely pure which makes testing and refactoring easier, and of course doesn't pollute the rest of the program.
- acomar 10y ago
  Unfortunately, not all monads are list-like (though there are a lot that are). The most notorious example is probably Cont[1], the monad of delimited continuations. State, ST, and IO all struggle to be interpreted as lists as well. [1]: http://blog.sigfpe.com/2008/12/mother-of-all-monads.html http://blog.sigfpe.com/2008/12/mother-of-all-monads.html

tomsmeding 10y ago

Bind is flatmap in the case of lists. Bind is way more generic than just the list monad, and the name "flatmap" doesn't apply to most other monads -- most of which are not List.

aninhumer 10y ago

Yes, bind is just flatMap. Various people seem to be arguing that "flatMap" only makes sense for Lists and similar containers, but I don't really see why. Yes, you have to broaden your notion of "flattening" to understand it, but I think that's a lot easier for people to learn than a "new" operation called "bind". I've been using Scala for a while after learning Haskell first (and understanding monads), and I've noticed how much more easily people understand flatMap, even for e.g. Futures.

chousuke 10y ago
Maybe it's just a difference of perspective, but I do not understand what is so intuitive about flatMap that makes it "easier". The name does not fully capture the idea of bind and requires mental gymnastics to apply to less concrete usecases, whereas bind is not so restricting, while still referring to the use of the abstraction as "glue" and hinting at its relation to composition.
- aninhumer 10y ago
  I think the thing that makes it more intuitive is that it's really easy to see how "flatMap" relates to "flatten" and "map", whereas it's not immediately obvious how "bind" relates to "join" and "map". And I think expanding a concept which someone already comfortably understands is a lot easier than asking them to learn a new one, even if you say it's kind of similar. And FWIW, I don't think "flatten" is particularly unintuitive name, even for the more abstract cases, because it's still f (f a) -> f a. The mental gymnastics here is understanding how a Functor can be more than just a container, and you kind of need to learn that anyway.

imh 10y ago

Bind is a great name. When you have a function that takes a monadic value of type `m a` (e.g. List[A_] in scala I think) it becomes convenient to program with lambda functions. For list comprehension, you can program like this (python notation now, since everyone reads it): bind(list_of_xs, lambda x: bind(list_of_ys, lambda y: return(x+y))) That's a list comprehension. You bind the monadic values (list_of_xs) to element values (x). On lines 2 and 3, you can think of x as a bound variable that was assigned to one of the elements of list_of_xs on line 1. Then we "assign" y on line 2, and it's in scope on line 3. "Assign" would have also been a decent name for it. It's way more intuitive for me to think of those three lines as assigning/binding x and y to be summed together, rather than thinking of one flatmap of a lambda to flatmap of a final lambda to a function. The abstraction of variable binding just fits.

jnordwick 10y ago
This isn't even close to being clear.