Re: [Haskell-cafe] Why Kleisli composition is not in the Monad signature?

Dan Doel wrote:

On Tue, Oct 16, 2012 at 10:37 AM, AUGER Cédric wrote:

...

join IS the most important from the categorical point of view. In a way it is natural to define 'bind' from 'join', but in Haskell, it is not always possible (see the Monad/Functor problem).

As I said, from the mathematical point of view, join (often noted μ in category theory) is the (natural) transformation which with return (η that I may have erroneously written ε in some previous mail) defines a monad (and requires some additionnal law).

This is the way it's typically presented. Can you demonstrate that it is the most important presentation?

I'd urge caution in doing so, too. For instance, there is a paper, Monads Need Not Be Endofunctors, that describes a generalization of monads to monads relative to another functor. And there, bind is necessarily primary, because join isn't even well typed. I don't think it's written by mathematicians per se (rather, computer scientists/type theorists). But mathematicians have their own particular interests that affect the way they frame things, and that doesn't mean those ways are better for everyone.

Right. Mathematical /conventions/ can and should be questioned. Sometimes they are not appropriate to the application domain. Sometimes the conventions are just stupid or obsolete even in a purely mathematical context (a well-known example is the extra "syntax sugar" for binomial coefficients, but there are worse ones), and you still find them in modern text books. Talk about "backwards compatibility"... My preference for Kleisli composition is because it makes the monad laws so much easier to write down and understand. Everywhere it is said that >>= must be "associative" and then the laws are written down for >>= and return and it is very hard to see what this "lambda grave" has to do with associativity or units. When I started with Haskell, this was all I could find. It was years later that I stumbled over a text that explained it with

=> and suddenly it all became simple and clear and I finally understood the monad laws!

=> in terms of >>= and vice versa, so that you can still use >>= as the

So, maybe >>= is the better primitive operation w.r.t. implementation, but IMO >=> is *much* more efficient w.r.t. understanding the monad laws. Since it is natural to explain the laws of a class using only class methods, I would prefer if >=> was added to the class with default implementations for primitive operation when implementing an instance. Cheers -- Ben Franksen () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments