Proposal: Applicative => Monad: Call for consensus

[Iavor Diatchki]

Hello,
In my experience, defining monads in terms of "fmap" and "join" leads to
code duplication.  The examples we have seen in this thread---so far---are a
bit misleading because they compare a partial implementation of a monad
(join without fmap) with a complete implementation (bind).  Here is an
example of what I mean:

data SP a               = PutChar Char (SP a)
                        | GetChar (Char -> SP a)
                        | Return a

fmapSP :: (a -> b) -> (SP a -> SP b)
fmapSP f (PutChar c sp) = PutChar c (fmapSP f sp)
fmapSP f (GetChar k)    = GetChar (\c -> fmapSP f (k c))
fmapSP f (Return a)     = Return (f a)

joinSP :: SP (SP a) -> SP a
joinSP (PutChar c sp)   = PutChar c (joinSP sp)
joinSP (GetChar k)      = GetChar (\c -> joinSP (k c))
joinSP (Return sp)      = sp

bindSP :: (a -> SP b) -> (SP a -> SP b)
bindSP f (PutChar c sp) = PutChar c (bindSP f sp)
bindSP f (GetChar k)    = GetChar (\c -> bindSP f (k c))
bindSP f (Return a)     = f a

I chose this example because I think that it illustrates nicely how the
three operators work, I hope that other readers find it useful.

2011/1/9 Conal Elliott <conal at conal.net>

> * The familiarity advantage of (>>=) is a historical accident. I like to
> see the language improve over time, rather than accumulate accidents.
>

I would be surprised if choosing ">>=" was an accident: it seems more likely
that it was chosen because it matches a commonly occurring pattern in
functional programs, and abstraction is all about giving names to common
patterns.  I completely agree with the sentiment of your second sentence but
I think that adding "join" to the Monad class would be an example of
"accumulating an accident" rather then simplifying things.

-Iavor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20110109/49f968e3/attachment.htm>