Split base into GHC and non-GHC parts

A general comment. It would be nice if base was split into GHC and non-GHC parts. But I’m just day dreaming.

7 Likes

The work I’ve been doing with Simon on known-keys !15899 will make it possible to move a lot of code from ghc-internal back into base. At which point, it’ll be normal code rather than re-exports. It doesn’t solve the whole thing, but it’s a good start!

10 Likes

To split base up into GHC-specific and GHC-independenty parts would be entirely possible.

But it depends on someone defining an API that is implementable by several compilers (notably both micro-hs and GHC), upon which base can depend and which can be implemented by each compiler separately.

You might wonder if that is precisely ghc-internal. But that’s not the case right now: ghc-internal is precisely what it says: internal to GHC and with no aspirations to be compiler independent.

Once someone defines a compiler-independent API on which base can depend (in a compiler-independent way) then we can see if it’s best addressed by splitting base, or by re-defining ghc-internal to meet that API.

In short: we have now removed all the technical difficulties with defining base atop a compiler-independent API. What remains is the question of who will design this compiler-independent API. The way lies open!

15 Likes