Thanks, Bob! I'm with on both counts: Monad is misrepresented as central in code composition; and (Monad m) => (a -> m b) -> (m a -> m b) is a much nicer type (for monadic extension), only in part because it encourages retraining away from sequential thinking. I encountered this nicer formulation only recently, and am glad to finally understand why I've been so uncomfortable with the type of (>>=).
- Conal 2009/1/15 Thomas Davie <tom.da...@gmail.com> > > On 15 Jan 2009, at 16:34, John Goerzen wrote: > > Hi folks, > > Don Stewart noticed this blog post on Haskell by Brian Hurt, an OCaml > hacker: > > http://enfranchisedmind.com/blog/2009/01/15/random-thoughts-on-haskell/ > > It's a great post, and I encourage people to read it. I'd like to > highlight one particular paragraph: > > > [snip] > Sorry, I'm not going to refer to that paragraph, instead, I'm going to > point out how depressing it is, that the message we're getting across to new > haskellers is that "Monads, and variations on monads and extensions to > monads and operations on monads are the primary way Haskell combines code-". > We have loads of beautiful ways of combining code (not least ofc, simple > application), why is it than Monad is getting singled out as the one that we > must use for everything? > > My personal suspicion on this one is that Monad is the one that makes > concessions to imperative programmers, by on of its main combinators (>>=) > having the type (>>=) :: (Monad m) => m a -> (a -> m b) -> m b, and not the > much nicer type (>>=) :: (Monad m) => (a -> m b) -> (m a -> m b). > > Bob > >
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
