[Haskell-cafe] Bind as a sequencing operator (Was: evaluation semantics of bind)

Jake McArthur writes:

mail@justinbogner.com wrote: | Oops, sent this off list the first time, here it is again. | | Jake McArthur writes: |> mail@justinbogner.com 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.