<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>I feel I need to clarify. Herbert granted me commit bits to text,
      so I can do small maintenance tasks on text, to not block GHC
      release process.<br>
      <br>
      However, this change is big and intrusive, and not explained
      anywhere. There is no wiki page explaining how the primops are
      changing.<br>
      <br>
      I feel I'm forced to accept the PR without having enough
      information to be able review it. So I will  merge that PR next,
      but all complaints are regarding possible problems should be
      directed to GHC maintainers.<br>
      <br>
      - Oleg<br>
      <br>
      P.S. <a class="moz-txt-link-freetext" href="https://i.imgflip.com/4xebid.jpg">https://i.imgflip.com/4xebid.jpg</a></p>
    <div class="moz-cite-prefix">On 17.2.2021 20.00, John Ericson wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:aa6b44b3-c471-af69-88db-e1b8ca95220e@obsidian.systems">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      <p>The way I see it, the primops are an implementation detail of
        GHC that---unfortunately, but like many others---leaks. If we
        are to stable interface, it should be a bunch of *un*boxed
        wrappers in a separate module that make no claims of being the
        actual primops. It's entirely the conflation of primops / prim
        types and unboxing that's led to the current unfortunate
        situation.</p>
      <p>Also, keep in mind that the precipitating change---that the
        boxed ones now wrapped the fixed-size types---has already
        happened, and had to happen to allow the Aarch64 NCG to land.
        Yes, these primops changes were already being planned, but the
        urgency for 9.2 is separate, and because we want:</p>
      <ul>
        <li>1 round, and not 2 rounds of breaking changes</li>
        <li>changing the primops and types being boxed together in fact
          leads to *less* breakage overall in many situations.</li>
      </ul>
      <p>So yes, I hope things can go differently in the future, but
        slamming the breaks on 9.2 at the last minute to ossify a leaked
        interface gets us too much of the costs of stabilizing without
        the benefits.<br>
      </p>
      <p>John<br>
      </p>
      <div class="moz-cite-prefix">On 2/17/21 12:38 PM, David Feuer
        wrote:<br>
      </div>
      <blockquote type="cite"
cite="mid:CAMgWh9vTsZ5u05sZcaBOa4KNp8=6pq5kN1VJfR_wA_KrTFLBew@mail.gmail.com">
        <meta http-equiv="content-type" content="text/html;
          charset=UTF-8">
        <div dir="auto">I still don't understand why GHC is making this
          change in such a breaky way without even going through the
          proposal process.</div>
        <br>
        <div class="gmail_quote">
          <div dir="ltr" class="gmail_attr">On Wed, Feb 17, 2021, 12:35
            PM John Ericson <a class="moz-txt-link-rfc2396E"
              href="mailto:john.ericson@obsidian.systems"
              moz-do-not-send="true"><john.ericson@obsidian.systems></a>
            wrote:<br>
          </div>
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex">
            <div>
              <p>Hi all,<br>
              </p>
              <p>First, background. I have a PR <a
                  href="https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4492"
                  target="_blank" rel="noreferrer"
                  moz-do-not-send="true">https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4492</a>
                that is one of the moving pieces for <a
                  href="https://gitlab.haskell.org/ghc/ghc/-/issues/19026"
                  target="_blank" rel="noreferrer"
                  moz-do-not-send="true">https://gitlab.haskell.org/ghc/ghc/-/issues/19026</a>,
                which is slated for 9.2 according to Ben's email <a
href="https://mail.haskell.org/pipermail/ghc-devs/2021-February/019478.html"
                  target="_blank" rel="noreferrer"
                  moz-do-not-send="true">https://mail.haskell.org/pipermail/ghc-devs/2021-February/019478.html</a>.
                (I just added the milestone to the issue to reflect
                this.)</p>
              <p>Despite this being a breaking change (to unstable
                interfaces) containers, bytestring, and binary could all
                updated in a way that didn't used CPP. (See the linked
                PRs in the GHC !4492's description). Text is a different
                case, because the unboxed computation there is more
                pervasive. The current PR is <a
                  href="https://github.com/haskell/text/pull/305"
                  target="_blank" rel="noreferrer"
                  moz-do-not-send="true">https://github.com/haskell/text/pull/305</a>,
                and uses CPP for 9.2. We have a few different options:<br>
              </p>
              <ul>
                <li>Keep as is. There will surely be no perf regressions
                  this way on any of the supported compilers. This does
                  however mean adding CPP for 9.2 before the associated
                  GHC change lands in master. I think that's
                  fine---inevitable even based on the current policy for
                  how GHC submodules are bumped---but it's given many
                  library maintainers the heebie jeebies.</li>
                <li>Try the same tricks in the other PRs of using
                  hyper-local unboxing that is easy to unbox away. This
                  will be a bit ugly however than the other cases, and I
                  am not sure whether it won't be a regression for the
                  oldest supported GHCs.</li>
                <li>Do the above, but bump the base version to the point
                  where there are no perf regressions with the oldest
                  supported GHCs (because those compilers are no longer
                  supported). If we bump the version more aggressively,
                  perhaps we can get rid of much of the unboxing
                  altogether / otherwise get rid of the ugliness.<br>
                </li>
              </ul>
              <p>We'll need to reach some sort of decision here to move
                forward.</p>
              <p>I'll also add that while Oleg Grenrus has helped merge
                a preparatory PR, Oleg expressed a <i>dis</i>interest
                in being de facto text maintainer, so I am emailing the
                list in part so this does not fall upon Oleg alone any
                longer.</p>
              <p>John<br>
              </p>
            </div>
            _______________________________________________<br>
            Libraries mailing list<br>
            <a href="mailto:Libraries@haskell.org" target="_blank"
              rel="noreferrer" moz-do-not-send="true">Libraries@haskell.org</a><br>
            <a
              href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries"
              rel="noreferrer noreferrer" target="_blank"
              moz-do-not-send="true">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
          </blockquote>
        </div>
      </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>