[Haskell-cafe] Why Kleisli composition is not in the Monad signature?
Ben Franksen
ben.franksen at online.de
Thu Nov 29 04:28:39 CET 2012
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
More information about the Haskell-Cafe
mailing list