Proposal: Slim base-5 API package

[Joachim Breitner]

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 at joachim-breitner.de • http://www.joachim-breitner.de/
  Jabber: nomeata at joachim-breitner.de  • GPG-Key: 0x4743206C
  Debian Developer: nomeata at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/libraries/attachments/20130715/1cfa1304/attachment.pgp>