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
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