Functor => Applicative => Monad

Simon Marlow marlowsd at gmail.com
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
>>>> http://haskell.org/haskellwiki/Functor-Applicative-Monad_Proposal,
>>>
>>> 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
>>> http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/14740 .
>>
>> 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 http://hackage.haskell.org/trac/ghc/ticket/4834 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.

Cheers,
	Simon



More information about the Libraries mailing list