[GHC] #710: library reorganisation

[Bulat Ziganshin]

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 at gmail.com