Simon Peyton-Jones wrote:
(c) Achieving (2) is jolly hard. Fully achieving it is probably impossible. And it's fragile: there are big recursive loops -- I think one involves IOException, and just one dependency can completely screw up a proposed separation. I think we could waste a lot of effort into trying to tease the two apart with little gain.
since we can't have two packages "ghc-base" and "new-base" that depend on each other. (so that they each export their own APIs). The canonical solution is to mash them into the same package that else uses, but from which parts are exported by "ghc-base" and "new-base". Like "secret-base" contains all the code, some of which is re-exported by "ghc-base" and some by "new-base". The proposal to move everything into "ghc-base" is saying "secret-base"="ghc-base", which is an acceptable solution if you don't mind "ghc-base" wantonly exporting everything. Someone suggested a "ghc-exts" package that would export only the sanctioned GHC.* modules. Then we have equality mapping Isaacs-secret-base = ghc-base Isaacs-ghc-base = ghc-exts Anyway we're probably going to end up with one package that has all the implementation, unless someone demonstrates that keeping some code in new-base would actually ever increase code sharing anywhere. I'm suggesting, 1) that we should probably recommend that user-level packages not import "secret-base", on the theory that even ghc-exts has a more stable/meaningful API? Discuss. and (2), we need a better name for it than "secret-base" or "ghc-base", maybe something like "base-internals"? -Isaac