base library and GHC 6.12

Simon Marlow marlowsd at
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
>      gain.
> 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
>       package.)
>     - 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
     details change

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 mailing list