base library and GHC 6.12

[Isaac Dupree]

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