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

[David Feuer]

Okay, but I still don't see the practical problem.

On Tue, May 5, 2020, 2:05 PM Andrew Martin <andrew.thaddeus at gmail.com>
wrote:

> 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 <david.feuer at gmail.com> wrote:
>
>> Why is that a problem? `Eq a` is still sufficient.
>>
>> On Tue, May 5, 2020, 1:51 PM Andrew Martin <andrew.thaddeus at gmail.com>
>> 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 <david.feuer at gmail.com>
>>> 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 . <chessai1996 at gmail.com> 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 at haskell.org
>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>>>>
>>>> _______________________________________________
>>>> Libraries mailing list
>>>> Libraries at haskell.org
>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>>>
>>>
>>>
>>> --
>>> -Andrew Thaddeus Martin
>>>
>>
>
> --
> -Andrew Thaddeus Martin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20200505/d31a8338/attachment.html>