| 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. All this is pretty much as Ian suggests. I'm just wanting to make sure we have the emphasis right. Simon