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

[Carter Schonwald]

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

On Tue, May 5, 2020 at 2:08 PM David Feuer <david.feuer at gmail.com> wrote:

> 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
>>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20200505/1a457742/attachment-0001.html>