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

On Thu, 2009-02-05 at 11:47 -0700, mail@justinbogner.com wrote:

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.

But not a temporal sequence. (>>=) in IO is about temporal sequencing (modulo unsafeInterleaveIO, forkIO, etc.)

The whole point of list comprehensions (which is the only reason to have a list monad, as far as I know)

Huh? I thought newtype Parser s alpha = Parser { unParser :: StateT s [] alpha } deriving (Functor, Applicative, Alternative, Monad, MonadPlus) was an entirely sufficient reason to have a list monad. jcc