Re: Reinstallable - base

Cut the Gordian Knot by serializing all the interfaces. This may be a good first step. Howard

On Oct 20, 2023, at 10:26 AM, Ben Gamari wrote:

Ben Gamari writes:

...

Simon Peyton Jones writes:

...

Dear GHC devs

Given the now-agreed split between ghc-internal and base https://github.com/haskellfoundation/tech-proposals/pull/51, what stands in the way of a "reinstallable base"?

Specifically, suppose that

- GHC 9.8 comes out with base-4.9 - The CLC decides to make some change to `base`, so we get base-4.10 - Then GHC 9.10 comes out with base-4.10

We thought about this quite a bit at the Well-Typed meeting this week. In short, I suspect that after the `ghc-internal` split is merged and some further work we will be able to use multiple `base` versions with a single compiler version.

I imagine this would be done in roughly three phases. The first two phases can happen in the short term; the last is a bit further off. I'll describe these in turn below.

One final point that I forgot to mention: None of this addresses the problem of compiler plugins. This is problematic as `Cabal`'s one-version-per-install-plan restriction means means that any package using a plugin will be forced to use the precise `base` that `ghc` itself is linked against.

I can think of three ways to address this:

* Teach `Cabal` to distinguish between plugin dependencies (which are only needed at build time and needn't be linked into final build results) and normal runtime dependencies. This is not a complete solution as many plugins have both compile-time and runtime components, but it would help in some cases.

* Make `ghc` reinstallable. This allows `Cabal` to rebuild the compiler when we need to link against a different `base`. We have started this process but in general it is quite tricky to get right (see #20742) and will require cooperation from `Cabal` .

* Serialise structures used by plugins, just as we do for the TH AST. Unfortunately, the surface area of the plugin interface is significantly larger than that of TH.

None of these options are easy. For this reason, I think it would be wise to leave plugins as future work (if we decide to address it at all). _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs