Text and changing number primops in GHC 9.2

[Oleg Grenrus]

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.

However, this change is big and intrusive, and not explained anywhere.
There is no wiki page explaining how the primops are changing.

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.

- Oleg

P.S. https://i.imgflip.com/4xebid.jpg

On 17.2.2021 20.00, John Ericson wrote:
>
> 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.
>
> 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:
>
>   * 1 round, and not 2 rounds of breaking changes
>   * changing the primops and types being boxed together in fact leads
>     to *less* breakage overall in many situations.
>
> 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.
>
> John
>
> On 2/17/21 12:38 PM, David Feuer wrote:
>> 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 <mailto:Libraries at haskell.org>
>>     http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
>
> _______________________________________________
> 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/ee96f766/attachment.html>