base library and GHC 6.12
simonpj at microsoft.com
Fri Jun 26 03:23:02 EDT 2009
| There has been some discussion recently about the base library. In
| particular, base is supposed to follow the PvP, which means that certain
| sorts of changes require increasing the version number. When the version
| number is increased, this makes work for lots of people, as any packages
| correctly using an upper bound on base's version number need to be
Just to add to Ian's message, I see two goals for the proposed split of the base package into two, say 'new-base' and 'ghc-base'. (Although 'new-base' will certainly be called 'base'; but it's easier to refer to it that way in this message.)
1. Stable interfaces
new-base will expose a relatively stable API. So its version
number will change relatively slowly, and packages that depend on
it will continue to work wihtout change. (They will still need to
be recompiled, but their package dependencies will be unchanged.)
ghc-base exposes a much larger, and much less stable API. Some
other packages need acces to these internals, and are prepared to
change more frequently as ghc-base changes.
2. Shared code
There is quite a bit of code in 'base' that is independent of any
particular compiler. But it's all mixed up with GHC-specific or
Hugs-specific code, with CPP-ery to keep them apart. It'd b cool
if new-base was compiler independent, with all the
compiler-dependent piecse in 'ghc-base'.
Now, some observations:
(a) Goal (1) is the Most Important Goal by far. It is the main reason
we are proposing to split up the base package in the first place.
Goal (2) is nice, but I don't think anyone has really been
seriously inconvenienced by the mixed up code in current 'base'.
(b) Goal (1) could be achieved by leaving ALL the code in ghc-base,
and making new-base into a package that simply imports goop from
ghc-base, and re-exports the stable API that new-base exposes.
That would fully achieve (1) and not achieve (2) at all.
(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
So I argue that we should focus on (1), and pick up as much of (2) as
convenient. Concretely I propose:
- That we split into two as proposed
- That the baseline starting point is (b) above: everything in
ghc-base. (Which suggests that is not a good name for the
- That we move as much stuff *as convenient* from ghc-base to
new-base. Ian's message suggests that quite a lot can actually
move, but *the details of what lives where does not matter much*.
- That we de-emphasise the idea that the compiler-independent stuff
goes in new-base and comiler-dependent stuff goes in ghc-base (or
hugs-base). If it makes sense otherwise, it's fine for there to
be compiler-specific stuff in new-base, and unavoidable (perhaps
dragged in by transitive dependencies) to have
compiler-independent stuff in ghc-base.
All this is pretty much as Ian suggests. I'm just wanting to make sure
we have the emphasis right.
More information about the Libraries