- 2008: `ghc-prim` and `integer` packages were spun off `base` to support several `integer` libraries (see fcf6b22d0478be20e27c2245f3e34dd272e12522) - 2020: `ghc-bignum` replaced the two integer libraries (`integer-simple` and `integer-gmp`). Instead bignum backends are selected with cabal flags for `ghc-bignum` since then. - 2024: `base` has been split into `ghc-internal` and `base` The proposal is to merge `ghc-bignum` and `ghc-prim` packages with `ghc-internal`. Reasons: 1. The split doesn't serve its initial purpose 1. We couldn't merge everything into `base` before (it wasn't supposed to contain GHC internal things), but in `ghc-internal` we can/should 2. Having 3 packages adds extra complexity (dependency bounds, hackage uploads, etc.). It's much simpler to explain that everything GHC exposes to Haskell programs comes from `ghc-internal` and that it is the only package tightly bound to a specific GHC ~~(with `template-haskell`, but I think we could merge part of it into `ghc-internal` too and only expose a stable TH interface from `template-haskell` package).~~ (done) 3. `ghc-prim` and `ghc-bignum` have implicit restrictions: they can't depend on anything defined in `ghc-internal`, yet GHC may introduce references to entities defined in `ghc-internal` (e.g. exceptions, see #18157). With a single package we could even use `.hs-boot` files for real cyclic dependencies like throwing an exception from `ghc-bignum`: for now we use a hack (ghc primops---defined in the rts---that raise a (wired-in) exception---defined in `ghc-internal`). For backward compatibility we could provide shallow `ghc-prim` and `ghc-bignum` packages that reexport modules that have been merged into `ghc-internal` (for a few releases).