Reinstallable - base

Adam Gundry adam at well-typed.com
Tue Oct 17 15:54:41 UTC 2023


Hi Simon,

Thanks for starting this discussion, it would be good to see progress in 
this direction. As it happens I was discussing this question with Ben 
and Matt over dinner last night, and unfortunately they explained to me 
that it is more difficult than I naively hoped, even once wired-in and 
known-key things are moved to ghc-internal.

The difficulty is that, as a normal Haskell library, ghc itself will be 
compiled against a particular version of base. Then when Template 
Haskell is used (with the internal interpreter), code will be 
dynamically loaded into a process that already has symbols for ghc's 
version of base, which means it is not safe for the code to depend on a 
different version of base. This is rather like the situation with TH and 
cross-compilers.

Adam



On 17/10/2023 11:08, Simon Peyton Jones wrote:
> 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
> 
> I think we'd all like it if someone could use GHC 9.10 to compile a 
> library L that depends on base-4.9 and either L doesn't work at all with 
> base-4.10, or L's dependency bounds have not yet been adjusted to allow 
> base-4.10.
> 
> We'd like to have a version of `base`, say `base-4.9.1` that has the 
> exact same API as `base-4.9` but works with GHC 9.10.
> 
> Today, GHC 9.10 comes with a specific version of base, /and you can't 
> change it/. The original reason for that was, I recall, that GHC knows 
> the precise place where (say) the type Int is declared, and it'll get 
> very confused if that data type definition moves around.
> 
> But now we have `ghc-internal`, all these "things that GHC magically 
> knows" are in `ghc-internal`, not `base`.
> 
> *Hence my question: what (now) stops us making `base` behave like any 
> other library*?  That would be a big step forward, because it would mean 
> that a newer GHC could compile old libraries against their old dependencies.
> 
> (Some changes would still be difficult.  If, for example, we removed 
> Monad and replaced it with classes Mo1 and Mo2, it might be hard to 
> simulate the old `base` with a shim.  But getting 99% of the way there 
> would still be fantastic.)
> 
> Simon

-- 
Adam Gundry, Haskell Consultant
Well-Typed LLP, https://www.well-typed.com/

Registered in England & Wales, OC335890
27 Old Gloucester Street, London WC1N 3AX, England



More information about the ghc-devs mailing list