<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<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"><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>
</body>
</html>