I think that's exactly right. Furthermore in https://gitlab.haskell.org/ghc/ghc/-/merge_requests/11400 the approach Ben has started going with is moving everything to ghc-internal to start, so this should be even easier --- surely we can reinstall an empty (except for reexports) library without the world falling down?! :)
I would love us to commit, day 0 of the split, to the principle that that base is now and forever more reinstallable. Then, as we move things back to base (untangling base's and ghc-internals's implementations), we'll be committing to not regressing on this. For example, if we want to move something back that GHC does in fact refer to, then we have to create the facility to make this not interfere with reinstallablilty before we move it. (I would eventually like things like NonEmpty that GHC only barely knows about, and which are perfectly standard bits of Haskell, to live in base not ghc-internals. Agda's and Rust's putting annotations on things to let the compiler know it should use them, rather than baking in names/locations into the compiler, is very good prior art that this can work.) John On Tue, Oct 17, 2023, at 6:08 AM, 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 > _______________________________________________ > 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
