It seems the root of one problem is the fact that base has a personality complex and does too many things with conflicting requirements.
In hindsight the framing I used in the start of this thread could have been better. By “alternative prelude” I really mean “standard library that is not tied to GHC and provides a few more batteries”.
One way to accomplish this would be to:
- rename the current
baselibrary toghc-base - provide new library called
base, versioned and released independently of GHC which re-exports most of whatbasecurrently exports minus the truly “internal” modules of theGHC.*namespace. Each major release ofbasewould be frozen modulo changes necessary to preserve compatibility with new GHC releases. Compatibility would be guaranteed with a reasonably generous window of GHC releases (three or five releases, perhaps?) - perhaps eventually further split up
ghc-basefollowing the model of @nomeata’s split-base proposal
Of course, there is a somewhat major hole in this plan: typeclasses. The basic typeclasses that we all rely on (e.g. Functor, Enum, Generic) would all need to live in ghc-base (in part because they have some special support in GHC and in part because otherwise you end up with instance-hell). This poses a challenge for proposals that want to change typeclass methods (e.g. removing a typeclass method, à la Monad of No return) or the typeclass hierarchy (e.g. adding a superclass à la Applicative-Monad Proposal) since these changes also require source-incompatible changes in downstream users.
This is a major problem that was discussed numerous times in the Foldable-Traversable, Applicative-Monad, and Semigroup-Monoid proposals. In short, there are a few ideas that may help mitigate much of the damage, but I don’t recall any approach that eliminates this source of breakage entirely.
Despite the typeclass problem, I suspect that this idea of versioning base independently of GHC would still pull its weight.