Reinstallable - base

Simon Peyton Jones simon.peytonjones at gmail.com
Tue Oct 17 10:08:02 UTC 2023


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20231017/2eb188c4/attachment.html>


More information about the ghc-devs mailing list