Hi, The problem =========== currently, base is a big beast that mixes a lot of different aspects, from really basic stuff like Data.List to quite specific system libraries like System.Console.GetOpt to gory GHC details such as GHC.Conc.Signal. There are various issues with this: * No implementation of a module included in base is able to use stuff from other libraries, like containers. There are even copies of container code in base. * Changes to the API of obscure modules like GHC.Conc.Signal require version bumps in base, which cause lots of depending packages to upload new version just to change their dependency. * The large expose surface of base makes refactoring like the actual split of the base implementation harder. * Compilers like haste or fay have a hard time providing a proper base, as many of the modules do not make sense in that setting. The suggestion ============== So I’d like to suggest that we turn the base package into a pure API package. This means that there will be no code in the package at all, only re-exports from other packages. The current code can then go into a base-ghc-impl package (or even many packages). Furthermore, the base package is stripped down to a sensible base API. Most, if not all, of the GHC package should go. There are other rather specific modules (Text.Show.Functions, Text.Read.Lex) where I am unsure whether they are useful in base. For such modules we will see if this is a good point to put them in a separate package. Also the module contents can be cleaned up at this point. The result should become base-5, and will hopefully be a more stable base library. „Below“ base-5 we can then wildly split and rearrange stuff, without disturbing our beloved users too much. Code that really needs the removed modules will have to build-depend on the implementing package and hence say „I really need these and I’m willing to pay by having to bump my dependencies more often.“ Way forward =========== If this is seen as mostly desirable here and by the maintainers, i.e. the committee that can become active ;-), the next step would be to identify a good base API. For that, we should study representative code on hackage: What modules from base have been importet, which functions are used. Based on that data I hope it will be clear what a good base is. Does someone have a tool around that can help with that? I guess compiling much of hackage with -ddump-minimal-imports and postprocessing that should work. If base-ghc-impl and base import the same module names (which would make sense), currently a library cannot depend on both libraries. This would be bad, as importing just one module from base-ghc-impl, and even only to test stuff, would require changing all imports (or use package imports). This can be avoided if we can add a feature GHC: Module re-exports. Similar to how GHC does not complain if the same definition is imported via different modules, it should not complain if the same Module is imported via different packages. A package re-export can either be an empty module import and exporting exactly one module, or an entry in the package metadata – but that’s an implementation detail. I have no roadmap with times at hand; maybe someone more knowledgeable of GHC and platform release processes and timings can comment on that. Dangers ======= The whole exercise will only be useful if afterwards, a large fraction of packages can actually use base and just base, and do not have to import the implementing packages directly. Hence the imports study in advance. There are lots of proposals floating around that modify base in a non-trivial manner. For some of them it might make sense to include them when bumping base to 5, but the danger is that there are too many, some of them rather intrusive, that it would hold up this proposal to decide on all of them. Also note that this proposal, if it goes as planned, will _not_ require code changes to _most_ packages. Which is good. Thanks for your attention, and please let us know what you think, Joachim -- Joachim “nomeata” Breitner mail@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata@joachim-breitner.de • GPG-Key: 0x4743206C Debian Developer: nomeata@debian.org