Functor => Applicative => Monad

Simon Marlow marlowsd at
Thu Dec 23 11:00:30 CET 2010

On 22/12/10 19:17, John Smith wrote:
> On 22/12/2010 19:03, Simon Marlow wrote:
>> On 14/12/2010 08:35, Isaac Dupree wrote:
>>> On 12/14/10 03:13, John Smith wrote:
>>>> I would like to formally propose that Monad become a subclass of
>>>> Applicative, with a call for consensus by 1 February. The change is
>>>> described on the wiki at
>>> That page isn't written as a proposal yet, it's written as a bunch of
>>> ideas. I would be happy to see something along the lines of Bas van
>>> Dijk's work
>>> .
>> This is a proposal with far-reaching consequences, and with several
>> alternative designs. I'm not sure I understand all
>> the tradeoffs. Some parts of the proposal are orthogonal to the rest
>> (e.g. changing fmap to map), and should probably be
>> considered separately.
>> Could someone please write a detailed proposal, enumerating all the
>> pros and cons, and the rationale for this design
>> compared to other designs?
>> Cheers,
>> Simon
> The wiki page was admittedly too broad of scope when I first wrote it,
> and it's getting broader with time.
> The ticket at has
> patches for only one change, making Monad a subclass of Applicative. (I
> would update the description to make this clear, but I can't edit the
> ticket description, so this has been relegated to a comment.)

Dealing with one issue at a time is great.  But even with this single 
change, we need to weight up the advantages and disadvantages - it's 
difficult to make an assessment without trawling through long email 
threads, and yet I don't want to let the proposal pass without comment. 
  So it would help a lot if someone could take the time to explain the 
design space and the tradeoffs.

I know for example I have lots of code that defines a Monad instance and 
doesn't need an Applicative instance, so this change will force me to 
jump through hoops that I don't need to.


More information about the Libraries mailing list