Functor => Applicative => Monad
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, and ticketed at http://hackage.haskell.org/trac/ghc/ticket/4834. As this would require a change to the prelude, it will presumably be necessary for GHC and the Haskell report to change in tandem. The Haskell' committee expects proposals to have been implemented before changing the standard, so I will propose this to Haskell' after it is accepted for GHC. Hopefully this will be sufficient to avoid a race condition.
This proposal will break every module which declares a monad instance
for some type. I expect that there will be many many broken
applications. Furthermore, if the only thing that I need is a monad
instance for some type, it is tedious do define Functor and
Applicative as well.
2010/12/14 John Smith
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, and ticketed at http://hackage.haskell.org/trac/ghc/ticket/4834.
As this would require a change to the prelude, it will presumably be necessary for GHC and the Haskell report to change in tandem. The Haskell' committee expects proposals to have been implemented before changing the standard, so I will propose this to Haskell' after it is accepted for GHC. Hopefully this will be sufficient to avoid a race condition.
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
On 14/12/2010 10:24, Krasimir Angelov wrote:
This proposal will break every module which declares a monad instance for some type. I expect that there will be many many broken applications. Furthermore, if the only thing that I need is a monad instance for some type, it is tedious do define Functor and Applicative as well.
This would break a lot of code, but this seems to happen anyway; most of hackage is broken on recent GHC. How many Monads are not instances of Applicative? These are the Monads which would require extra work, whereas the Applicative Monads would require less. (Most Monads are currently defined twice; once as Monads, then boilerplate instances for Applicative Functors.)
2010/12/14 John Smith
This would break a lot of code, but this seems to happen anyway; most of hackage is broken on recent GHC.
At least this should be clearly stated on your proposal page. Now it isn't even mentioned but it should be written with LARGE BOLD LETTERS. None of the breakages caused by GHC was so deep. This should be made first into language extension proposal because it really affects the language and not just the libraries.
How many Monads are not instances of Applicative? These are the Monads which would require extra work, whereas the Applicative Monads would require less. (Most Monads are currently defined twice; once as Monads, then boilerplate instances for Applicative Functors.)
Of course it is possible to change the affected code and to add the necessary instances. The point is that if I am going to use only the functionality of Monad and I don't care of Functor and Applicative then I don't define them at all. I add them only later if I need them.
On Tue, Dec 14, 2010 at 10:02:42AM +0100, Krasimir Angelov wrote:
Of course it is possible to change the affected code and to add the necessary instances. The point is that if I am going to use only the functionality of Monad and I don't care of Functor and Applicative then I don't define them at all. I add them only later if I need them.
For consistency: If you are going to use only the functionality of Ord and don't care about Eq, you don't want to define Eq at all? (Such cases are realistic, for example for using Data.Map and Data.Set.) I have some tools that allow you to just define the methods with their standard names, but outside any instance (which in many cases is good practice anyways), and then let the tool throw them together into instances for the class hierarchy du jour: http://www.cas.mcmaster.ca/~kahl/Haskell/ModuleTools/ Wolfram ------------------------------------------------------------ @InProceedings{Kahl-2009_TFP, author = {Wolfram Kahl}, title = {Haskell Module Tools for Liberating Type Class Design}, crossref = {TFP2009}, pages = {129--144}, chapter = {9}, abstract = {Design of Haskell type class hierarchies for complex purposes, including for standard containers, is a non-trivial exercise, and evolution of such designs is additionally hampered by the large overhead of connecting to existing implementations. We systematically discuss this overhead, and propose a tool solution, implemented using the GHC API, to automate its generation.} } @Book{TFP2009, title = {Trends in Functional Programming, {TFP 2009}}, booktitle = {Trends in Functional Programming, {TFP 2009}}, year = 2010, editor = {Zolt\'an Horv{\'a}th and Vikt\'oia Zs{\'o}k and Peter Achten and Pieter Koopman}, address = {UK}, publisher = {Intellect}, URL = {http://www.intellectbooks.co.uk/books/view-Book,id=4740/} }
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 . -Isaac
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
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.)
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
participants (5)
-
Isaac Dupree -
John Smith -
kahl＠cas.mcmaster.ca -
Krasimir Angelov -
Simon Marlow