Skip to content

Merge ghc-prim and ghc-bignum into ghc-internal

  • 2008: ghc-prim and integer packages were spun off base to support several integer libraries (see fcf6b22d)
  • 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
  2. We couldn't merge everything into base before (it wasn't supposed to contain GHC internal things), but in ghc-internal we can/should
  3. 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)
  4. 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 (closed)). 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).

Edited by Sylvain Henry
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information