Text and changing number primops in GHC 9.2

[John Ericson]

Hi all,

First, background. I have a PR 
https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4492 
<https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4492> that is one 
of the moving pieces for 
https://gitlab.haskell.org/ghc/ghc/-/issues/19026 
<https://gitlab.haskell.org/ghc/ghc/-/issues/19026>, which is slated for 
9.2 according to Ben's email 
https://mail.haskell.org/pipermail/ghc-devs/2021-February/019478.html 
<https://mail.haskell.org/pipermail/ghc-devs/2021-February/019478.html>. 
(I just added the milestone to the issue to reflect this.)

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 https://github.com/haskell/text/pull/305 
<https://github.com/haskell/text/pull/305>, and uses CPP for 9.2. We 
have a few different options:

  * 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.
  * 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.
  * 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.

We'll need to reach some sort of decision here to move forward.

I'll also add that while Oleg Grenrus has helped merge a preparatory PR, 
Oleg expressed a /dis/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.

John

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20210217/87325363/attachment.html>