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