<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi all,<br>
</p>
<p>First, background. I have a PR <a moz-do-not-send="true"
href="https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4492">https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4492</a>
that is one of the moving pieces for <a moz-do-not-send="true"
href="https://gitlab.haskell.org/ghc/ghc/-/issues/19026">https://gitlab.haskell.org/ghc/ghc/-/issues/19026</a>,
which is slated for 9.2 according to Ben's email <a
moz-do-not-send="true"
href="https://mail.haskell.org/pipermail/ghc-devs/2021-February/019478.html">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
moz-do-not-send="true"
href="https://github.com/haskell/text/pull/305">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>
</body>
</html>