Reinstallable - base

[Howard B. Golden]

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 <ben at well-typed.com> wrote:
> 
> Ben Gamari <ben at well-typed.com> writes:
> 
>> Simon Peyton Jones <simon.peytonjones at 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 at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs