base library and GHC 6.12
ml at isaac.cedarswampstudios.org
Fri Jun 26 13:16:17 EDT 2009
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
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"?
More information about the Libraries