GHC 8.10 backports?

Moritz Angermann moritz.angermann at
Mon Mar 22 06:02:56 UTC 2021

The commit message from
makes the changes to string seem required. Applying the commit on its own
doesn't apply cleanly and pulls in quite a
bit of extra dependent commits. Just applying the elem rules appears rather
risky. Thus will I agree that having that
would be a nice fix to have, the amount of necessary code changes makes me
rather uncomfortable for a minor release :-/

On Mon, Mar 22, 2021 at 1:58 PM Gergő Érdi <gergo at> wrote:

> Thanks, that makes it less appealing. In the original thread, I got no
> further replies after my email announcing my "discovery" of that commit, so
> I thought that was the whole story.
> On Mon, Mar 22, 2021, 13:53 Viktor Dukhovni <ietf-dane at>
> wrote:
>> On Mon, Mar 22, 2021 at 12:39:28PM +0800, Gergő Érdi wrote:
>> > I'd love to have this in a GHC 8.10 release:
>> >
>> This is already in 9.0, 9.2 and master, but it is a rather non-trivial
>> change, given all the new work that went into the String case.  So I am
>> not sure it is small/simple enough to make for a compelling backport.
>> There's a lot of recent activity in this space.  See also
>> <>, which is not
>> yet merged into master, and might still be eta-reduced one more step).
>> I don't know whether such optimisation tweaks (not a bugfix) are in
>> scope for backporting, we certainly need to be confident they'll not
>> cause any new problems.  FWIW, 5259 is dramatically simpler...
>> Of course we also have
>> <> in much the
>> same territory, but there we're still blocked on someone figuring out
>> what's going on with the 20% compile-time hit with T13056, and whether
>> that's acceptable or not...
>> --
>>     Viktor.
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the ghc-devs mailing list