Re: Improving the instances of Data.Functor.{Product,Sum}
John Ericson <[email protected]>
| Newsgroups | gmane.comp.lang.haskell.libraries |
|---|---|
| Organization | Obsidian Systems |
| Message-ID | <[email protected]> |
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 >> [email protected] >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > _______________________________________________ > Libraries mailing list > [email protected] > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries _______________________________________________ Libraries mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries