There is a somewhat weak prescriptive argument that one shouldn't use these things for long term usage, e.g. that you put, say a WrappedMonad shim on just for long enough to pass something and get a different dictionary, but really the result is it just makes code harder to test, debug and work with at a REPL and raises the question of what components should people be using when they DO need to embed such a thing in a place where it winds up visible or stored in a container. I'm generally positive on adding these kinds of instances, especially where they don't require us to go out and lean on UndecidableInstances and the like. -Edward On Mon, Oct 14, 2013 at 1:55 PM, David Luposchainsky < dluposchainsky@googlemail.com> wrote:

On 2013-10-14 18:33, Eric Mertens wrote:

...

It would be handy for Control.Applicative.Const to have the various derivable instances (Eq, Ord, Read, Show).

Let me ask the other way round: is there ever a reason to *not* add these instances if they're possible and unambiguous?

David _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

On Mon, Oct 14, 2013 at 07:43:31PM -0400, Edward Kmett wrote:

Alternately we could just hand-roll the instances so it doesn't change whether it gets imported if the user writes

import Control.Applicative (Const(..))

but I agree with simplifying the presentation.

Hand-rolling is possible, but it's more transparent to use the derived instances.