Proposal: Applicative => Monad: Call for consensus
iavor.diatchki at gmail.com
Mon Jan 3 03:27:04 CET 2011
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).
On Sun, Jan 2, 2011 at 4:04 AM, John Smith <voldermort at hotmail.com> wrote:
> 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
> 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 at haskell.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Libraries