Proposal: reduce base from the top

Simon Marlow simonmarhaskell at gmail.com
Tue Apr 3 06:21:34 EDT 2007


This is an attempt to propose a set of changes that we could reasonably make in 
the GHC 6.8 timeframe, that would significantly reduce the size of base and give 
us more flexibility to independently develop packages.

This is not an attempt to solve all the issues we have in one go, but a 
practical incremental step towards the goal.  I'm not trying to make base 
compiler-independent for example; that's a worthy goal, but it's not clear (at 
least to me) how to get there yet.  What I'm doing here is disentangling the 
dependencies from the top down.  We started on this path before GHC 6.6 (see 
http://hackage.haskell.org/trac/ghc/ticket/710), this proposal will clarify some 
the details of the next stage.

There may be dependencies I've missed, but as far as I'm aware all of the 
following is possible without any significant rewriting of code.  These 
reoganisations will allow more reuse: for example, more libraries will be able 
to make direct use of the unix/Win32 packages rather than being limited to the 
primitives available in the base package, so cleanups will be possible after the 
reoganisation.  There are several things I'm not completely sure about, and some 
naming issues to resolve, so please take a look and comment if you can.

I'll make one request regarding comments: please don't suggest renaming modules 
at this point.  There are various modules whose names I'm aware are contentious, 
but I think it would be a distraction to discuss those as part of this proposal; 
let's do it separately.

Here goes:

System.Time
--> new package old-time (dep. on unix/Win32)

System.Locale
--> new package old-locale

System.Posix.Signals
--> unix (System.Cmd depends on it, but moves to new package process)

System.Directory
--> new package directory (dep. on filepath, unix/Win32)
     System.Directory.Internals goes away, use filepath instead

Data.Array.*
--> new package array (maybe; I'm slightly dubious here)
     (dep. on concurrent for Data.Array.Diff)

Data.Generics.*
--> generics (maybe; Data class is defined for everything and is derivable)

Data.ByteString.*
--> fps (dep. on base, generics, array)

Control.Concurrent.*, System.Timeout
--> new package concurrent
     (needed by Data.Unique, where to move it?)

Control.Parallel.*
--> new package parallel

System.Process, System.Cmd
--> new package process (dep. on concurrent)

Control.Applicative
Data.Foldable, Data.Traversable
Data.Map, Data.IntMap, Data.Set, Data.IntSet
Data.Sequence, Data.Tree
Data.HashTable
Data.Graph
---> new package collections? containers?  or split further?
      (dep. on array, generics, concurrent)

System.Console.GetOpt
---> new package getopt? consoleutils?

Text.PrettyPrint.*
---> new package pretty

System.Random
---> new package random (modify to use time, not old-time)

Other modules we could move: Text.Printf, Data.Unique, Data.Monoid, System.CPUTime.


Topological sort of core packages with dependencies
---------------------------------------------------
base
unix/Win32       (base)
generics         (base)
concurrent       (base)
parallel         (base)
filepath         (base)
Cabal            (base)
readline         (base)
regex-base       (base)
regex-posix      (base, regex-base)
regex-compat     (base, regex-base, regex-posix)
parsec           (base)
stm              (base)
template-haskell (base)
pretty           (base) (could drop from core-packages)
getopt           (base) (could drop from core-packages)
old-locale       (base)
old-time         (base, unix/Win32)
array            (base, generics, concurrent)
fps              (base, generics, array)
process          (base, unix/Win32, concurrent)
directory        (base, unix/Win32, filepath)
time             (base, unix/Win32)
random           (base, unix/Win32, time)
haskell98        (old-time, old-locale, random, directory, process)
containers       (base, array, generics, concurrent)


More information about the Libraries mailing list