library reorganisation

[simonmar]

This is the place I'm going to record the planned reorganisations to the packages we ship with GHC. Some of this may happen for 6.6. Please comment.

Goals

• make the base package less monolithic by extracting parts into separate packages

• hence reduce the amount of library code that needs to be built to bootstrap GHC.

• make it possible to build and ship GHC with a minimal set of libraries, without removing the possibility of delivering it with a more comprehensive set too.

• packages provided with a GHC installation should be upgradable.

Activities

• GHC's libraries need to be built using Cabal. Some of the things we need to do before this can happen:

• Cabal needs support for using a specific package database
• we need to support -split-objs with --make

• Abstract away from the particular packages that are built in the GHC tree. Make It possible to populate libraries with any Cabal packages you like, which are built and installed with GHC. (subject to the minimum requirements: base, haskell98, unix, template-haskell, readline, ...).

Library reorganisation

The following modules could be removed from base (perhaps not exhaustive, and there may be dependencies I haven't considered):

• Control.Applicative
• Data.Array.*
• Data.Foldable
• Data.Graph
• Data.HashTable (replace with Jan-Willem Maessen's version)
• Data.IntMap
• Data.IntSet
• Data.Map
• Data.Monoid
• Data.Sequence
• Data.Set
• Data.Traversable
• Data.Tree
• Text.Html (to network package?)
• Text.PrettyPrint.*
• Text.Printf
• Text.Regex (integrate with, or replace by,  JRegex?)

Some libraries we want to add:

•  FastPackedStrings (replace Data.PackedString)

These were deprecated in 6.4, and can be removed now:

• Data.FiniteMap
• old interface in Data.Set
• withObject in Foreign.Marshal.Utils

These are deprecated now, and can be removed later:

• Data.FunctorM
• Data.Queue

[Neil Mitchell]

Moving Text.Html into networks sounds like a really bad idea - Html is a textual format, it just so happens that its often used over a network (the web), but fundamentally it has nothing to do with networks at all.

If it really wants moving out of Text, then maybe Formats.Html, Text.Formats.Html - something that says its a textual format/document.

[maeder@…]

from a user's point o view it is incomprehensible that (deprecated!) Data.FiniteMap? and Data.Array.* remains in package base, but Data.Map should be moved (to package data?). The choice above only reveals the current ghc dependencies.

[ekarttun]

Considering moving GHC specific modules out of base could make sense.

Foreign.Concurrent GHC.* System.Mem.*

[simonmar]

Partially done:

• Text.Html moved into its own package

• Text.Regex removed from base and replaced by Chris Kuklewicz's regex packages

• Data.HashTable? replaced by Jan Willem Maessen's improved version

• Data.ByteString?.* was added

• Various deprecated things were removed (Data.FiniteMap?, old Data.Set API)

• GHC now comes with a cut-down set of packages, with the full set of packages optionally included.

I didn't get around to taking up all the other suggestions for slimming down base, so that will have to wait until 6.8.

[igloo]

I spent some time looking at this. There are a number of issues that need to be resolved, or at least it would be better if they could be resolved first:

• Problem using --make when compiling the base package (#909).
• We'd lose the ability to do parallel module building within each library (#910).
• Currently the implementations don't agree on what Read is, as the new ReadP requires rank-2 or rank-n polymorphism. I am told Haskell' will have one or the other, so this will come in time.
• The code used by default class definitions needs to be pretty low down in the hierarchy, and in particular fail s = error s in the Monad class pulls in the huge exception type. This might be simplified with an extensible exception replacement?
• For the deps from common packages to impl-specific packages we obviously need some sort of conditional support in Cabal.
• Standalone deriving declarations (separate from the data declaration) make some things a lot easier. I think bringert has a working implementation for GHC, but it only truly helps if it's in all impls; something for Haskell'?
• It's unfortunate that we can't make imported and exported class instances explicit, so the compiler won't be checking that we are giving consistency across impls.

In what follows, I haven't given a huge amount of thought to names, but I don't think there's any need to do so yet.

My conclusions were that ultimately something like this would be good (with <impl> replaced with ghc, hugs, ...):

• <impl>-prim at the bottom; defines things like the Int type (basically all the types and functions needed by the next layer.
• base-types-classes next, which just have class declarations but probably no instances.
• <impl>-base next; This is where all GHC's instances with I#'s etc would go.
• base on top of that, with anything that can't be forked off into another package.

I also managed to fork off

• array
• containers (Data.{FunctorM, Foldable, Graph, IntMap, IntSet, Map, Set, Queue, Sequence, Tree, Traversable)
• bytestring
• printf

and it also looked plausible that io and/or concurrency would also be able to be pulled out, but by that point I had run into enough of the issues above that I stopped working on it. The rest can be looked at in more detail when we come to do this for real.

[simonmar]

Some of this has been done, and we have a new proposal for splitting the base package, so I created a new ticket rather than mangle the description in this one: #1338.