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.davie@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