<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>With the recent approval of
<a class="moz-txt-link-freetext" href="https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4527">https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4527</a>, I
thought it might be good to revisit this. I implemented my plan in
<a class="moz-txt-link-freetext" href="https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4727">https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4727</a>.</p>
<p>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.</p>
<p>I hope we can make progress here,</p>
<p>John<br>
</p>
<div class="moz-cite-prefix">On 5/19/20 10:51 AM, John Ericson
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:661b20b7-20a9-09db-9585-2cdd4a853f69@obsidian.systems">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<blockquote type="cite"
cite="mid:CAHYVw0yYmBe2QBGYZgsW74+Y1iKSxEhb=T6ELczTBa=Bq_gRAw@mail.gmail.com">
<div>
<div dir="auto">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div>
<div>The different results are:<br>
</div>
<div>* FlexibleContexts approach: `(Eq (Maybe (f
a)), Eq [f a])`</div>
<div>* Eq1 typeclass: `(Eq1 f, Eq a)`</div>
<div>* Quantified Constraints: `(forall x. Eq x
=> Eq (f x), Eq a)`</div>
</div>
</div>
</blockquote>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
<p>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.</p>
<blockquote type="cite"
cite="mid:CAHYVw0yYmBe2QBGYZgsW74+Y1iKSxEhb=T6ELczTBa=Bq_gRAw@mail.gmail.com">
<div>
<div dir="auto">I think we should pre address any maturity
issues or composition/ generality concerns before folding
quantified constraint instances into base <br>
</div>
</div>
</blockquote>
<p>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.<br>
</p>
<p>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.]</p>
<p>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.<br>
</p>
<p>John</p>
<p>[1]: So nobody need waste their time looking it up, the super
class is (forall x. Eq x => Eq (f x)) => Eq1 f<br>
</p>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Libraries mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Libraries@haskell.org">Libraries@haskell.org</a>
<a class="moz-txt-link-freetext" href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a>
</pre>
</blockquote>
</body>
</html>