<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Bump. It looks like both my MR (!4727) and this email went
      unnoticed?<br>
    </p>
    <div class="moz-cite-prefix">On 1/4/21 1:59 AM, John Ericson wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:fb7e3abc-eaf0-6f94-705d-f4c29dacd81e@obsidian.systems">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      <p>With the recent approval of <a class="moz-txt-link-freetext"
          href="https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4527"
          moz-do-not-send="true">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"
          moz-do-not-send="true">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" moz-do-not-send="true">Libraries@haskell.org</a>
<a class="moz-txt-link-freetext" href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" moz-do-not-send="true">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a>
</pre>
      </blockquote>
      <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>