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

[Jonathan Cast]

On Thu, 2009-02-05 at 11:47 -0700, mail at justinbogner.com wrote:
> Jake McArthur <jake at pikewerks.com> writes:
> > mail at justinbogner.com wrote:
> > | Oops, sent this off list the first time, here it is again.
> > |
> > | Jake McArthur <jake at pikewerks.com> writes:
> > |> mail at 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