Jake McArthur <[email protected]> writes: > [email protected] wrote: > | Oops, sent this off list the first time, here it is again. > | > | Jake McArthur <[email protected]> writes: > |> [email protected] wrote: > |> | Bind is a sequencing operator rather than an application operator. > |> > |> In my opinion, this is a common misconception. I think that bind would > |> be nicer if its arguments were reversed. > | > | If this is a misconception, why does thinking of it this way work so > | well? This idea is reinforced by the do notation syntactic sugar: bind > | can be represented by going into imperative land and "do"ing one thing > | before another. > > An imperative-looking notation does not make something imperative. > > Thinking of bind as sequencing really *doesn't* work very well. What > does bind have to do with sequencing at all in the list monad, for > example? What about the reader monad? > > - Jake
What doesn't bind have to do with sequencing in the list monad? Consider: [1..2] >>= return . (^2) This says "generate the list [1..2] and then use it to generate a list of squares". It's more than just application, it's a description of a sequence of actions. The whole point of list comprehensions (which is the only reason to have a list monad, as far as I know) is to think of it this way rather than as an application of concatMap. As for Reader, I don't know enough about it to say anything. _______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
