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