Extract the GHC.Compat modules to a standalone package

[pepeiborra]

ghcide comes with a custom GHC compatibility library that covers from 8.6 to 9.2 thanks to the recent summer project by @fendor.

Extracting these modules to a standalone package would enable reuse in other projects.

[jneira]

• It would be good to have some comparation with other projects with the same goal as ghc-lib and ghc-api-compat, to help make clear the point of create a new package
• The subset of compat definitions would fit other projects generically? or it follows closely the concrete needs of ghcide?

[fendor]

+1, would reduce the amount of CPP in e.g. hiedb.

However, extracting it in a reasonable format is a bit tricky. I propose that it needs to fit the concrete needs of ghcide for now, providing a backwards compat package for everyone will be just a nightmare to maintain.

[jneira]

Right, i think we should carefully focus the scope of the library, as ghc-api-compat has suffered several problems due to be generic and cover all ghc api

[pepeiborra]

Let me elaborate on what I have in mind here:

1. Extract all the Development.IDE.Compat.GHC modules to a Cabal package with a more neutral namespace, e.g. Compat.GHC
2. Upload that package to Hackage
3. Accept PRs from third parties who want to improve or extend the package.

@fendor can you elaborate on what would be tricky about extracting it?

@jneira can you be more specific on what problems has ghc-api-compat suffered?

[fendor]

Let me elaborate on what I have in mind here:

Perfect.

can you elaborate on what would be tricky about extracting it?

Nothing tricky implementation wise.
Thinking about the scope, support, etc...
Low-level backwards compat vs high-level backwards compat.
But given this plan, we are going to figure it out.

ghc-api-compat suffered from multiple things:

• cabal check is imperfect and made it harder than necessary to upload
• it provided no help with renaming of important identifiers, or added constructors, etc... It was just a renaming of the module hierarchy... Backwards! Undoing everything GHC has done in the last year to reorganise the module hierarchy, not solving the upgrading issue, but postponing it until either the end of time, or until ghc-api-compat drops support. So, the design was flawed from the very beginning.
• Also, trying to be backwards compatible for every identifier is just a huge amount of work.
• Lacking design-goals (at least in my opinion)

I think our GHC Compat has at least one significant design goal: We go with the latest GHC API (E.g. UnitId vs Unit vs InstalledUnit), all older GHC's try to satisfy the new API (I think that's roughly forward compatibility?). This way we can easily drop old GHC versions and can still experiment with the latest features.

[fendor]

One more thing I just remember is that when we extract ghcide-ghc-compat (or whatever name is fitting here), it is easy to add it to head.hackage (maybe too much maintenance for head.hackage?), noticing breaking changes way earlier (maybe even allowing an IDE to use with GHC HEAD?).
Previously this was virtually impossible since ghcide depends already on way too much of the ecosystem to be viably added to head.hackage in my opinion.

This would be a great step towards having some minimal IDE available immediately after a GHC release.