# GHC 9.6 Migration Guide

**URL:** <https://discourse.haskell.org/t/ghc-9-6-migration-guide/5730>\
**Category:** Links\
**Created:** [February 2, 2023, 9:14pm UTC](https://discourse.haskell.org/t/ghc-9-6-migration-guide/5730 "2023-02-02T21:14:24Z")\
**Posts on this page:** 16\
**Page:** 1

<div class="post-metadata">

**Author:** ![bgamari](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/bgamari/32/3599_2.png) [@bgamari](https://discourse.haskell.org/u/bgamari)\
**Post date:** [February 2, 2023, 9:14pm UTC](https://discourse.haskell.org/t/ghc-9-6-migration-guide/5730/1 "2023-02-02T21:14:24Z")

</div>

Hello all,

Part of GHC’s release process that has been historically under-advertised is our migration guide, where we document the major user-visible changes made in the compiler and its core libraries.

Today we are happy to share the [migration guide for GHC 9.6](https://gitlab.haskell.org/ghc/ghc/-/wikis/migration/9.6). Our hope is that this guide serves as a useful resource for those porting their projects to GHC 9.6. Note that this is a living document which we hope the community can help maintain. If you notice anything missing please do bring it to our attention.

Cheers,

~ Ben

---

<div class="post-metadata">

**Author:** ![bgamari](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/bgamari/32/3599_2.png) [@bgamari](https://discourse.haskell.org/u/bgamari)\
**Post date:** [February 4, 2023, 4:15pm UTC](https://discourse.haskell.org/t/ghc-9-6-migration-guide/5730/2 "2023-02-04T16:15:19Z")

</div>

20 posts were split to a new topic: [Language, library, and compiler stability](https://discourse.haskell.org/t/language-library-and-compiler-stability/5745)

---

<div class="post-metadata">

**Author:** ![Kleidukos](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/kleidukos/32/1213_2.png) [@Kleidukos](https://discourse.haskell.org/u/Kleidukos)\
**Post date:** [February 3, 2023, 7:30am UTC](https://discourse.haskell.org/t/ghc-9-6-migration-guide/5730/3 "2023-02-03T07:30:05Z")

</div>

@bgamari I’m very glad this kind of document is being produced! 🙂  
One more step towards automating the production of compatibility patches.

I’m not a user of type-changing record updates myself but I’m wondering why the rejection of the code couldn’t have been put behind a flag just like the other warning that we have for record update, `-Wambiguous-fields`.

---

<div class="post-metadata">

**Author:** ![ocharles](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/ocharles/32/102_2.png) [@ocharles](https://discourse.haskell.org/u/ocharles)\
**Post date:** [February 3, 2023, 10:24am UTC](https://discourse.haskell.org/t/ghc-9-6-migration-guide/5730/4 "2023-02-03T10:24:07Z")

</div>

Thanks @bgamari! Could I ask that the migration guide be completed with fixes? For example, in "  
Type-changing record updates involving type families" there are two explanations to fix the problem. It’d be really useful to make this completely precise by providing code examples of both of those fixes.

Edit: actually it might just be this point that needs a code example, the next migration does have the fix illustrated.

---

<div class="post-metadata">

**Author:** ![adamgundry](https://avatars.discourse-cdn.com/v4/letter/a/34f0e0/32.png) [@adamgundry](https://discourse.haskell.org/u/adamgundry)\
**Post date:** [February 3, 2023, 10:54am UTC](https://discourse.haskell.org/t/ghc-9-6-migration-guide/5730/5 "2023-02-03T10:54:38Z")

</div>

Bear in mind that the previous state of record updates for GADTs was complex, buggy and ill-specified. The new design is much clearer: simply apply the translation of record updates in the Report.

GHC frequently fixes bugs with the side effect that code that was (accidentally) relying on the bug ceases to work. Volunteer contributors aren’t going to be pleased if every patch that fixes a bug also has to introduce a warning, retain/test the old code path for two versions, etc. and it seems like it would lead to a significant increase in the internal code complexity. Basically I don’t think it is feasible to have GHC maintain bug-for-bug compatibility between versions without a very substantial increase in the resources going in to maintenance.

---

<div class="post-metadata">

**Author:** ![adamgundry](https://avatars.discourse-cdn.com/v4/letter/a/34f0e0/32.png) [@adamgundry](https://discourse.haskell.org/u/adamgundry)\
**Post date:** [February 3, 2023, 11:04am UTC](https://discourse.haskell.org/t/ghc-9-6-migration-guide/5730/6 "2023-02-03T11:04:58Z")

</div>

> [@Kleidukos](#):
>
> I’m not a user of type-changing record updates myself but I’m wondering why the rejection of the code couldn’t have been put behind a flag just like the other warning that we have for record update, `-Wambiguous-fields`.

I think the situation with `-Wambiguous-fields` was a bit different because there we had a clearly-specified existing feature that the GHC steering committee decided to deprecate (via the proposals process). The proposal specified the warning for code that had been relying on the feature, and the intended migration path (although there are some details still to resolve there).

In contrast, with GADT record updates in 9.6, there was no well-defined existing feature being deprecated, rather a collection of bugs were being fixed by giving a proper specification to something that previously lacked one.

Of course there is always a judgement call to be made about whether a bug fix that breaks existing programs is significant enough to warrant extra effort on backwards compatibility. But that extra effort has very real costs.

---

<div class="post-metadata">

**Author:** ![Kleidukos](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/kleidukos/32/1213_2.png) [@Kleidukos](https://discourse.haskell.org/u/Kleidukos)\
**Post date:** [February 3, 2023, 11:24am UTC](https://discourse.haskell.org/t/ghc-9-6-migration-guide/5730/7 "2023-02-03T11:24:57Z")

</div>

Thank you for the context! 🙂

---

<div class="post-metadata">

**Author:** ![jaror](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/jaror/32/3271_2.png) [@jaror](https://discourse.haskell.org/u/jaror)\
**Post date:** [February 3, 2023, 11:27am UTC](https://discourse.haskell.org/t/ghc-9-6-migration-guide/5730/8 "2023-02-03T11:27:42Z")

</div>

> [@adamgundry](#):
>
> giving a proper specification to something that previously lacked one.

Would it be a good idea to document similar unspecified parts of the compiler such that people who care about backwards compatibility can avoid those parts? Even better if a tool like HLint or Stan could be used to warn you automatically when you are using those parts.

---

<div class="post-metadata">

**Author:** ![ocharles](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/ocharles/32/102_2.png) [@ocharles](https://discourse.haskell.org/u/ocharles)\
**Post date:** [February 4, 2023, 4:02pm UTC](https://discourse.haskell.org/t/ghc-9-6-migration-guide/5730/28 "2023-02-04T16:02:08Z")

</div>

I suggest that the discussions about both compiler stability and the SWG be broken out to separate threads and we keep this one focused on the 9.6 migration guide

---

<div class="post-metadata">

**Author:** ![bgamari](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/bgamari/32/3599_2.png) [@bgamari](https://discourse.haskell.org/u/bgamari)\
**Post date:** [February 4, 2023, 4:15pm UTC](https://discourse.haskell.org/t/ghc-9-6-migration-guide/5730/29 "2023-02-04T16:15:25Z")

</div>

Yes, I agree. I will break out the last 20-or-so posts into a new thread.

---

<div class="post-metadata">

**Author:** ![bgamari](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/bgamari/32/3599_2.png) [@bgamari](https://discourse.haskell.org/u/bgamari)\
**Post date:** [February 4, 2023, 4:16pm UTC](https://discourse.haskell.org/t/ghc-9-6-migration-guide/5730/30 "2023-02-04T16:16:15Z")

</div>

I have broken out the discussion of general stability concerns into a new thread, [Language, library, and compiler stability](http://discourse.haskell.org/t/language-library-and-compiler-stability/5745).

---

<div class="post-metadata">

**Author:** ![dandart](https://avatars.discourse-cdn.com/v4/letter/d/8e8cbc/32.png) [@dandart](https://discourse.haskell.org/u/dandart)\
**Post date:** [February 9, 2023, 5:18pm UTC](https://discourse.haskell.org/t/ghc-9-6-migration-guide/5730/31 "2023-02-09T17:18:25Z")

</div>

Thanks! This will be very helpful. I’m looking forward to not having to use third party libraries for SNat etc.

---

<div class="post-metadata">

**Author:** ![Mikolaj](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/mikolaj/32/1041_2.png) [@Mikolaj](https://discourse.haskell.org/u/Mikolaj)\
**Post date:** [February 18, 2023, 3:36pm UTC](https://discourse.haskell.org/t/ghc-9-6-migration-guide/5730/32 "2023-02-18T15:36:47Z")

</div>

I have trouble finding in the 9.6 migration guide where `GHC.Tc.Types.Evidence.mkTcSymCo` and `GHC.Tc.Types.Evidence.mkTcTransCo` have gone. Search for `Evidence` comes up empty, but perhaps I missed some more general remark that covers this. Listing all affected module names would certainly be helpful for users that have no idea what they are doing and just try to blindly apply the guide to whatever error messages pop up.

Anyway, thank you for the guide, it’s been very helpful so far.

Edit: alternatively, a stable link to (pre-alpha) haddocks of the new version of the affected APIs would work ([https://downloads.haskell.org/ghc/9.6.1-alpha3/docs/libraries/ghc/index.html](https://downloads.haskell.org/ghc/9.6.1-alpha3/docs/libraries/ghc/index.html) is 404).

---

<div class="post-metadata">

**Author:** ![amesgen](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/amesgen/32/2083_2.png) [@amesgen](https://discourse.haskell.org/u/amesgen)\
**Post date:** [February 19, 2023, 5:38pm UTC](https://discourse.haskell.org/t/ghc-9-6-migration-guide/5730/33 "2023-02-19T17:38:42Z")

</div>

> Edit: alternatively, a stable link to (pre-alpha) haddocks of the new version of the affected APIs would work ([https://downloads.haskell.org/ghc/9.6.1-alpha3/docs/libraries/ghc/index.html](https://downloads.haskell.org/ghc/9.6.1-alpha3/docs/libraries/ghc/index.html) is 404).

@Mikolaj Here you go: [ghc-9.6.0.20230210: The GHC API](https://downloads.haskell.org/ghc/9.6.1-alpha3/docs/libraries/ghc-9.6.0.20230210/index.html)

I _think_ this has been fixed as of [#22714: Broken interpolation in GHC `master` haddocks · Issues · Glasgow Haskell Compiler / GHC · GitLab](https://gitlab.haskell.org/ghc/ghc/-/issues/22714)

---

<div class="post-metadata">

**Author:** ![Mikolaj](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/mikolaj/32/1041_2.png) [@Mikolaj](https://discourse.haskell.org/u/Mikolaj)\
**Post date:** [February 19, 2023, 6:05pm UTC](https://discourse.haskell.org/t/ghc-9-6-migration-guide/5730/34 "2023-02-19T18:05:41Z")

</div>

Oh, great, thank you @amesgen.

---

<div class="post-metadata">

**Author:** ![Mikolaj](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/mikolaj/32/1041_2.png) [@Mikolaj](https://discourse.haskell.org/u/Mikolaj)\
**Post date:** [February 19, 2023, 7:46pm UTC](https://discourse.haskell.org/t/ghc-9-6-migration-guide/5730/35 "2023-02-19T19:46:12Z")

</div>

it seems `GHC.Tc.Types.Evidence.mkTcSymCo` and `GHC.Tc.Types.Evidence.mkTcTransCo` have gone to `GHC.Plugin` with a name simplification. I guess a mention in the guide wouldn’t hurt, even if `GHC.Plugin` is an old invention (is it?). In any case, the three famous ghc-tcplugins-extra and ghc-typelits-\* plugins compile fine now, after minor adjustments. I will create PRs.