Proposal: Applicative => Monad: Call for consensus
Simon Marlow
marlowsd at gmail.com
Wed Jan 5 11:33:56 CET 2011
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
More information about the Libraries
mailing list