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 <b...@well-typed.com> wrote: > > Ben Gamari <b...@well-typed.com> writes: > >> Simon Peyton Jones <simon.peytonjo...@gmail.com> 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 _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs