Re: Proposal: Applicative => Monad: Call for consensus

On 03/01/2011 22:30, Bas van Dijk wrote:

On Mon, Jan 3, 2011 at 12:43 PM, Ian Lynagh 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