Hello GHC, Wednesday, September 27, 2006, 9:32:37 PM, you wrote:

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.

i will start answering from this easy part. First, ByteString - it was just integrated and it should be still easy enough to deintegrate this again. but after that, ByteString package should be included in list of extra packages array - look at my ArrayRef lib: http://haskell.org/haskellwiki/Library/ArrayRef http://www.haskell.org/library/ArrayRef.tar.gz except for a few still unfinished features, it's almost completely backward compatible with ghc 6.6 arrays implementation. so, i propose to use it, although some code may require to move between base and arrayref libs. say, unboxed references or GHC.* modules may be better looking in base lib while Ix class (which, i think, is compiler-independent) should be moved out of base. Also, HashTable and may be some other code is Array-dependent (although, on the other side, it may be easily rewritten to use only array primitives described in GHC.ArrBZ) containers, i.e. almost whole Data.* hierarchy - definitely yes other packages may be also based on existing hierarchies - Foreign.*, System.* GHC Handle I/O, i.e. GHC.Hanle, GHC.IO and part of GHC.IOBase - should be moved to separate package at some time. just because this I/O package are rather cumbersome and i hope that it will be replaced by Streams-like package concurrency - definitely. nothing depends on it, and it's separate concept that may be even not implemented in other compilers. but we should first decide where to place primitive operations (i.e. GHC.Conc) - leave them in base package or bundle into the same package as high-level operations? i prefer the first variant. btw, STM package is already playing by these rules Text.* - it would be great to move this into separate package, allowing to make alternative Read/Show implementations but it seems impossible because GHC deriving mechanism use these concrete implementation printf - i think it's too small to make any separate package -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com