Pre-Pre-HFTP: Decoupling base and GHC

We don’t want to do that because we want (the new) base to be portable across GHC versions (and other hypothetical implementations) at all times. The empty library is trivially portable, and we move over definitions only if they are also.

…and right now (2022 Feb) that would require going as close to fully-parameterised (no type classes) as possible

I am interested in these things, but I don’t think overly opinionated instances in GHC are a problem. (Outputable is opinionated but structured errors mean that pretty-printing is increasingly moved to the outskirts!)

If you want to talk to about orphan instances more, would you mind forking that to a new thread? It is orthogonal to the low hanging initial steps for both making GHC a real library and decoupling base.

Acknowledged. I’ve just searched for orphan here to see if there was an existing Discourse thread - this appeared in the results:

…which mentioned this:

which in turn refers to this:

May you be more successful.


Thanks! That is very useful. I am generally a fan of rebasing things no matter how ancient, so I should take a crack at rebasing @nomeata’s changes even though they are a decade old.

From it’s readme

Some changes are just work-arounds due to GHC having the package name base hardcoded

Yes we should definitely get that more flexible so we don’t need to rebuild the compiler are stuff merely moves around. Settings file, maybe?

1 Like

Proposal: Relax instances for Functor combinators; put superclasses on <class>1 to make less-breaking · Issue #10 · haskell/core-libraries-committee · GitHub I wrote up a new benefit that even the most trivial “beachhead” of making ghc-base contain everything and base reexport it all would realize.

1 Like
1 Like





with each being a “standardised snapshot” of:


in which all the latest products of active research debuts. The haskell package can also serve as the point of separation (or abstraction) between base and GHC, allowing the two to evolve at their own pace.

Everyone else can then choose the level of stability and compatibility most suitable for their Haskell project.


Standard library reform by Ericson2314 · Pull Request #47 · haskellfoundation/tech-proposals · GitHub I have opened a draft tech proposal on this.