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

[John Ericson]

Bump. It looks like both my MR (!4727) and this email went unnoticed?

On 1/4/21 1:59 AM, John Ericson wrote:
>
> With the recent approval of 
> https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4527, I thought it 
> might be good to revisit this. I implemented my plan in 
> https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4727.
>
> I point a hope the concrete implementation will make clear is that the 
> flexible contexts and quantified constraints are *complementing*, not 
> *competing*. You can do the flexible instance without the quantified 
> constraint, but if you do the breakage will be worse, and the only 
> newly-allowed programs will be dubious ones that did the *1 instance 
> but forgot the corresponding regular instance.
>
> I hope we can make progress here,
>
> John
>
> On 5/19/20 10:51 AM, John Ericson wrote:
>>>
>>>         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
>>
>>
>> _______________________________________________
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20210125/599313a7/attachment.html>