Text and changing number primops in GHC 9.2

[David Feuer]

I still don't understand why GHC is making this change in such a breaky way
without even going through the proposal process.

On Wed, Feb 17, 2021, 12:35 PM John Ericson <john.ericson at obsidian.systems>
wrote:

> Hi all,
>
> First, background. I have a PR
> 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,
> which is slated for 9.2 according to Ben's email
> 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, 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
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20210217/5332f114/attachment.html>