Hello,
I think that reorganizing the Monad/Applicative/Functor classes is a good
idea, despite the fact that it would break lots of code. However, 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 (having the patches is
nice, but they are hard to read).
-Iavor
On Sun, Jan 2, 2011 at 4:04 AM, John Smith
The patches attached to http://hackage.haskell.org/trac/ghc/ticket/4834make Applicative a superclass of Monad. Default definitions are provided for backwards compatibility.
Advantages: The class hierarchy correctly models the logical relationship between Applicative and Monad. Boilerplate Applicative instances that duplicate Monad functions will no longer be required.
Disadvantage: All Monads will be Applicatives, even if you're only interested in the Monad interface. This is akin to all Ords being Eqs, even if you're not using ==.
Backwards Compatibility: Existing Monad definitions will have to be changed to declare Applicative. The original function bodies can be used unchanged, but they are now declared in a different class. Calling code should work unchanged.
This ticket has already been discussed on the mailing lists. The purpose of this message is to call for consensus by the deadline of 1 February.
Please note that although the ticket references the wiki page at http://haskell.org/haskellwiki/Functor-Applicative-Monad_Proposal, the patches attached to the ticket are much more conservative than the more ambitious reforms on the wiki. (I would like to change the ticket description to make this clearer, but I can't edit it.)
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries