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

[Ben Franksen]

Dan Doel wrote:
> On Tue, Oct 16, 2012 at 10:37 AM, AUGER Cédric <sedrikov at gmail.com> 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!

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 
>=> in terms of >>= and vice versa, so that you can still use >>= as the 
primitive operation when implementing an instance.

Cheers
-- 
Ben Franksen
()  ascii ribbon campaign - against html e-mail 
/\  www.asciiribbon.org   - against proprietary attachments