GHC-9.8 backwards compatibility?

[gergoerdi]

I looked at what it would take to still support GHC 9.8 with develop as of 5595507d943cb00f92674c19a5cbafcd93dff92b and it's so little that I think it would be feasible with just a little CPP usage to keep supporting 9.8. For comparison, Clash, which is a similarly involved user of the GHC API, manages to support all GHC versions between 8.10 and 9.10.

• [x] foldl' is not exported by the Prelude, so has to be imported from Data.List. A triviality that affects 8 files. The imports can be guarded by CPP macros if we want to avoid "redundant imports" warnings on GHC 9.10.

• [x] Uniques are built from Ints, not Word64s. Handling this difference can be centralized by adding a type alias and some utility functions to some new Liquid.GHC.API.Compat module.

• [x] Instead of GHC.Internal.Foldable and GHC.Internal.Real, we have Data.Foldable and GHC.Real. Again, can be worked around by defining aliases in Liquid.GHC.API.Compat.

• [ ] Differences in AST annotations / TTG expansion points: This is very annoying, because it requires CPP branching at five places across three modules.

• [ ] tcValBinds has a slightly different type, requiring a change in Language.Haskell.Liquid.GHC.Misc.withWiredIn.

Overall, I don't think it would be that big a burden to keep GHC 9.8 around.

[gergoerdi]

I've pushed the change for the first three issues to https://github.com/gergoerdi/liquidhaskell/tree/ghc-9.8-compat

I've got code locally that "fixes" the remaining problems (by breaking the GHC 9.10 compatibility), so at least we can know there's no other "unknown unknowns" lurking.

[facundominguez]

On the side of costs, we would need to make sure patches pass tests in both compiler versions. The hardest thing to support is probably going to be the move of many definitions from base to ghc-internals, which affects the annotations in the liquidhaskell package and wired-in names in the code.

I'd prefer having a separate branch for ghc-9.8 and backporting fixes there when needed, rather than making harder to accept contributions to the develop branch. It seems to me like it would allow to better share the maintenance effort.

For the reference, here is the issue (#2307) and the PR (#2316) about the upgrade to 9.10.1.

[gergoerdi]

I'd prefer having a separate branch for ghc-9.8 and backporting fixes there when needed

So would you be happy with me starting a new branch off current develop, where I'd push all the GHC 9.8 compatibility changes (without CPP-guarding them) as a new baseline for this branch going forward? Otherwise, I'm worried things will keep drifting further and further apart.

[facundominguez]

where I'd push all the GHC 9.8 compatibility changes (without CPP-guarding them) as a new baseline for this branch going forward?

That works. There are two strategies to maintain that:

1. Add backports of patches from develop on top.
2. Rebase the compatibility changes every now and then on top of the latest develop.

In either case, I suppose CI will need to be reverted to use GHC 9.8 on that branch.

One other thought that comes to mind: it might be worth encapsulating the compatibility changes so the differences between develop and develop-ghc-9.8 spread over as little files as possible.