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