Proposal: Applicative => Monad: Call for consensus

[Simon Marlow]

On 03/01/2011 22:30, Bas van Dijk wrote:
> On Mon, Jan 3, 2011 at 12:43 PM, Ian Lynagh<igloo at earth.li>  wrote:
>> On Sun, Jan 02, 2011 at 06:27:04PM -0800, Iavor Diatchki wrote:
>>>
>>> I think
>>> that it would be useful if there was a wiki page which describes the
>>> proposal exactly, so that we can discuss the details
>>
>> I agree. I'm confused as to what is part of the proposal, what are other
>> changes necessary due to the classes changing, what are orthogonal
>> cleanups, and what is not being proposed.
>
> The patch for base makes a few changes:
>
> 1) Make Applicative a superclass of Monad. So the new hierarchy becomes:
>
> class  Functor f  where
>      fmap        :: (a ->  b) ->  f a ->  f b
>
>      (<$)        :: a ->  f b ->  f a
>      (<$)        =  fmap . const
>
> class Functor f =>  Applicative f where
>      pure :: a ->  f a
>
>      (<*>) :: f (a ->  b) ->  f a ->  f b
>
>      (*>) :: f a ->  f b ->  f b
>      a *>  b = fmap (const id) a<*>  b
>
>      (<*) :: f a ->  f b ->  f a
>      a<* b = fmap const a<*>  b
>
> class Applicative m =>  Monad m  where
>      (>>=) :: forall a b. m a ->  (a ->  m b) ->  m b
>      m>>= f = join $ fmap f m
>
>      join :: m (m a) ->  m a
>      join m = m>>= id
>
>      (>>) :: forall a b. m a ->  m b ->  m b
>      (>>) = (*>)
>
>      return :: a ->  m a
>      return = pure
>
>      fail :: String ->  m a
>      fail s = error s

We have a hard time explaining Monads to people already.  But now the 
entire API goes from being one class with 3 methods (only 2 of which you 
need to care about) to being 3 classes with a total of 11 methods, with 
a lot of complex interactions.  That's a significant increase in 
cognitive overhead.  It might well be the "right" thing in some sense, 
but is it really worth the pain?  What about all those monad tutorials? 
  They now have to include some Functor/Applicative boilerplate, and 
hope it doesn't put the reader off too much.  I like Applicative, I 
really do, but I want it to be something you only have to buy into if 
you want to.

Someone knocking up a monad for a simple job now has to define 3 
instances, not one.  So it affects not just people learning the 
language, but also those already familiar with it and trying to get the 
job done.

Furthermore, we have some significant compatibility issues with Haskell 
98/2010 code.  I wouldn't be in favour of doing this unless we can 
retain Haskell 98/2010 compatibility somehow (e.g. with superclass 
defaults or class aliases).

Cheers,
	Simon