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

[John Ericson]

>         The different results are:
>         * FlexibleContexts approach: `(Eq (Maybe (f a)), Eq [f a])`
>         * Eq1 typeclass: `(Eq1 f, Eq a)`
>         * Quantified Constraints: `(forall x. Eq x => Eq (f x), Eq a)`
>
So if (per my plan[1]) `Eq1` has the quantified constraints 
super-class,than Andrew Martin's second two options will imply the first 
one. So it seems that the FlexibleContexts choice --- asking for 
precisely what is needed --- is the best option, dare I say a principle 
type.

> I think we should pre address any maturity issues or composition/ 
> generality concerns before folding quantified constraint  instances 
> into base

I am with you Carter, but the only issues with quantified constraints 
we've discussed is around (~) and Coercible, but both shouldn't apply 
here, so I think that's a red-herring.

In particular, only the *1 classes would have a *wanted* quantified 
constraint via super class (so just one imposed on instances). 
Everything else would just use FlexibleContexts or stay the same. [Extra 
given constraints do not in and of themselves pose inference problems.]

It is because the *1 classes do not involve (~) or Coercible, or have 
anything like a `Type -> Constraint` parameters that could be 
substituted for (partially applied) (~) or Coercible, that those 
concerns shouldn't apply.

John

[1]: So nobody need waste their time looking it up, the super class is 
(forall x. Eq x => Eq (f x)) => Eq1 f

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20200519/67c00d00/attachment.html>