Decoupling built-in data types from GHC?

[rpglover64]

Continuing the discussion from Pre-Pre-HFTP: Decoupling base and GHC:

@simonpj

One possiblity is this. Consider an entity E, where “entity” means type, data constructor, class, or function.

• If GHC has specific knowlege of E, then E is GHC-specific. In GHC-jargon, these are the “wired-in” things and the “known-key” things.
• If a GHC-specific entity E’ depends on E, then E is also GHC-specific.
• Everything else is pure-library

One cool thing I remember from reading Agda code is that the stdlib defines things like Bool and List and tells the compiler “here is your definition of list” with a pragma. Porting the idea to Haskell would mean that GHC would be able to indirectly depend on the list in base rather than the other way around.

• Is there anything fundamental about the difference between Agda and Haskell that invalidates the comparison?
• Is this just a lot of work?
• Is this the kind of thing Backpack enables?
• Is GHC in principle able to use backpack like this?

[atravers]

Let’s (politely :-) ask those who have taken on the associated challenge:

Modularizing GHC, do we want an HFTP?

@hsyl20 and, more recently, @doyougnu have done excellent work untangling GHC, in particular banishing DynFlags and HscEnv from as many modules as possible. Many of the refactors are quite hard, not because they are necessarily technically advanced, but because GHC is a labyrinth that would make Thesus blush, and so breaking down this task into manageable chunks requires great wisdom and patience. However, once the plan is made, executing on it isn’t always so hard. I just stumbled upon a modul…

…it have been a few months since their paper was initially published: @Ericson2314, is there any good news? (I’m cautiously assuming this effort will help in some way to also disentangle base from GHC.)

[david-christiansen]

Another bit of related work is Rust’s lang_items: lang_items - The Rust Unstable Book