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

You're right. I botched that. The scenario I meant to describe was: foo :: _ => f a -> f a -> Bool foo x y = Compose (Just x) == Compose (Just y) && Compose [x] == Compose [y] 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)` Only the FlexibleContexts approach mentions Maybe and [] in the constraints. On Tue, May 5, 2020 at 1:56 PM David Feuer wrote:

Why is that a problem? `Eq a` is still sufficient.

On Tue, May 5, 2020, 1:51 PM Andrew Martin wrote:

...

I dislike the FlexibleContexts approach because it gives you constraints that do not compose. Consider this minimal example:

foo :: _ => a -> a -> Bool foo x y = Compose (Just (Just x)) == Compose (Just (Just y)) && Compose [Just x] == Compose [Just y]

What do we expect the constraint to be? With the Eq1 machinery or with QuantifiedConstraints, it's `Eq a` (GHC will infer this). However, with FlexibleContexts, it's `(Eq (Compose Maybe Maybe a), Eq (Compose [] Maybe a)`.

On Tue, May 5, 2020 at 12:45 PM David Feuer wrote:

...

I oppose the QuantifiedConstraints version because:

1. It is more complicated than the FlexibleConstraints one.

2. It is strictly less general than the FlexibleConstraints one.

3. There is no apparent benefit to pay for detriments 1 and 2.

On Fri, Mar 13, 2020, 11:59 PM chessai . 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]: https://mail.haskell.org/pipermail/libraries/2019-July/029771.html [2]: https://gitlab.haskell.org/ghc/ghc/issues/17015 [3]: https://gitlab.haskell.org/ghc/ghc/merge_requests/1704 _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

-- -Andrew Thaddeus Martin

-- -Andrew Thaddeus Martin