On Thu, 2009-02-05 at 11:47 -0700, [email protected] wrote:
> 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.
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
_______________________________________________
Haskell-Cafe mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-cafe
