Improving the instances of Data.Functor.{Product,Sum}

Eric Mertens emertens at
Sat Mar 14 04:14:09 UTC 2020

I prefer to avoid FlexibleInstances wherever I can. The last thing I'd
heard about quantified constraints was that they were buggy and I've been
avoiding relying on them. (I should probably review that assumptions at
some point.) Having a class like Eq1 is the cleaner option. I'd rather fix
up these classes than work to get rid of them.

On Fri, Mar 13, 2020 at 8:59 PM chessai . <chessai1996 at> wrote:

> Consider the Eq instance for these types. Currently we rely on:
> (Eq1 f, Eq1 g, Eq a)
> But some potential improvements include changing to:
> (Eq (f (g a))) (FlexibleContexts)
> or
> (forall x. Eq x => Eq (f x), forall x. Eq x => Eq (g x), Eq a)
> (QuantifiedConstraints)
> There was a discussion sometime last year about the same thing
> regarding Semigroup/Monoid instances for `Compose` [1]. Additionally,
> the question has been raised again for Data.Functor.{Product,Sum} on
> Gitlab [2, 3]. There has been no consensus in either case, but that's
> not too worrying as both discussions have been brief. I'm currently
> not happy with the {Eq,Ord,Show}{1,2} family of classes, and would
> hope to work toward their removal, or at least the shrinking of their
> presence in base. Even though the linked proposals are about a single
> type, I think it's important that we come up with a decision and stick
> with it. Having different APIs for different types here would be
> pretty confusing, and some could even say sloppy.
> Please let me know your thoughts.
> [1]:
> [2]:
> [3]:
> _______________________________________________
> Libraries mailing list
> Libraries at

Eric Mertens
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Libraries mailing list