On Thu, 2009-02-05 at 11:47 -0700, m...@justinbogner.com wrote: > Jake McArthur <j...@pikewerks.com> writes: > > m...@justinbogner.com wrote: > > | Oops, sent this off list the first time, here it is again. > > | > > | Jake McArthur <j...@pikewerks.com> writes: > > |> m...@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 _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe