Hello Simon, Tuesday, April 3, 2007, 2:21:34 PM, you wrote:

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.

i'm all for this plan. long way starts with first step about "making base compiler-independent". its *interface* is already compiler-independent. if you say about implementation, it seems rather obvious for me - split it into ghc-base package that includes GHC.* and modules on which GHC.* depend and new-base package which contains the rest. then move any "#ifdef GHC" code into from new-base into *hc-base. then, as time permits, we can start to move ghc-independent code from ghc-base into new-base. meantime, faking Base package may be established that just reexports ghc-base and new-base, so user will not depend on where we moved each particular module my Core library was actually an attempt to separate GHC.* into ghc-specific and ghc-independent part of course, it's entirely separate proposal, we can return to discussing it in some future, probably after your plan will be implemented -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

On Tue, Apr 03, 2007 at 11:21:34AM +0100, Simon Marlow wrote:

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. [...] 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)

Data.HashTable (and thus Data.Array.*) is used in the implementation of Data.Typeable. It also differs from the others in being a mutable data structure. I imagine that without it this package wouldn't need to depend on array and concurrent. Data.Monoid could possibly go here too. Another possibility is to split the 4 class modules from the concrete data structures.

simonmarhaskell:

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)

Yep, but we might call it the 'bytestring' package as Ian suggests. I'm good with this.

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) _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

On 4/3/07, Simon Marlow wrote:

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)

Applicative seems more related to Functor, Monad, and Arrow than to the collections. Even its haddock page mentions parsers before Traversable. I think Control.Applicative should stay in base or follow Control.Arrow if that moves somewhere else. -- Namasté, Jeffrey Yasskin