base library and GHC 6.12
marlowsd at gmail.com
Fri Jun 26 12:01:06 EDT 2009
On 26/06/2009 08:23, Simon Peyton-Jones wrote:
> | 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
> | updated.
> 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.
I fully agree that (2) is hard. Having thought about this a bit more,
I'm tending towards moving *no code at all* into new-base, keeping it as
a pure re-export of bits from base-internals only. It's much simpler:
- we always know where the code is
- there's no arbitrary split based on implementation details
- we never have to move things just because the implementation
I don't think moving just some of the modules is going to make life
easier for anyone, and it'll make life more complicated for some of us.
More information about the Libraries