Proposal: Applicative => Monad: Call for consensus

Maciej Piechotka uzytkownik2 at gmail.com
Sun Jan 16 10:44:12 CET 2011


On Sat, 2011-01-15 at 22:43 -0500, Jan-Willem Maessen wrote:
> 
> Which of course says nothing about which form is easier to *write*,
> but I'm inclined to believe that it's easiest to read and write the
> form whose use you understand best (ie brevity is not the sole
> criterion here by any means; understandability has to be paramount).
> My bias is to assume my reader is, like me, a programmer first and a
> mathematician second.  For example, I find it relatively easy to
> understand >>= in the continuation monad, but have to spend a long
> time puzzling my way through join.  For simple stuff like [] and
> Maybe, of course, the code complexity argument is moot, and join is
> pretty natural unless you spend your time re-formulating list
> comprehensions for fun.
> 
> -Jan-Willem Maessen
> 

I agree that there are advantages of both ways and they are perfectly
compatible with each other. While I don't know about GHC internals I'd
assume that class v-tables (term borrowed from C++ I'm not sure about
Haskell terminology) is per-class and not copied for each function
invocation. Therefore if we can include both ways which can be
interleaved (Monad written by 'join' person can be used by 'bind' person
and vice-versa) why don't do that?
I don't think there is anyone who propose to remove (>>=) from Monad
class. 

As of simplification - I find join simpler as it allows to pattern match
in some cases and have one 'complicated' parameter less. You may find
bind simpler as it is closer to imperative style. However I often use
(>>=)/do notation.

Regards

PS. I don't think I constitute a mathematician - I don't know much about
theory of categories except pieces I learn along Haskell.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/libraries/attachments/20110116/010b3650/attachment.pgp>


More information about the Libraries mailing list