Merge ghc-prim and ghc-bignum into ghc-internal
- 2008:
ghc-primandintegerpackages were spun offbaseto support severalintegerlibraries (see fcf6b22d) - 2020:
ghc-bignumreplaced the two integer libraries (integer-simpleandinteger-gmp). Instead bignum backends are selected with cabal flags forghc-bignumsince then. - 2024:
basehas been split intoghc-internalandbase
The proposal is to merge ghc-bignum and ghc-prim packages with ghc-internal. Reasons:
- The split doesn't serve its initial purpose
- We couldn't merge everything into
basebefore (it wasn't supposed to contain GHC internal things), but inghc-internalwe can/should - 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-internaland that it is the only package tightly bound to a specific GHC(with(done)template-haskell, but I think we could merge part of it intoghc-internaltoo and only expose a stable TH interface fromtemplate-haskellpackage). -
ghc-primandghc-bignumhave implicit restrictions: they can't depend on anything defined inghc-internal, yet GHC may introduce references to entities defined inghc-internal(e.g. exceptions, see #18157 (closed)). With a single package we could even use.hs-bootfiles for real cyclic dependencies like throwing an exception fromghc-bignum: for now we use a hack (ghc primops---defined in the rts---that raise a (wired-in) exception---defined inghc-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).
Edited by Sylvain Henry