base libraries

[Sven Panne]

Hmmm, this whole base library reoganization discussion gets a little bit long 
a confusing, because quite a few things are mixed up IMHO, so I don't even 
know to which mail I should reply...

Just a few miscellaneous thoughts about this area:

 * Splitting up libraries in tiny little packages does not only have 
advantages. Even if every small package is well-tested, there is no guarantee 
at all that it will work well with the rest of the packages. If we split up 
things more and more, this problem will get more severe, because probably 
nobody will have the same set of versioned packages as somebody else => 
testing nightmare!

 * There are other quite successful libraries out there, which are very 
monolithic: Java's standard libraries, Boost, etc.  Their advantage is: If I 
download version XY of them, I get a consistent, well-tested library.

 * Bulat wants to do several things at once, if I understand it correctly: a) 
Split the compiler-dependent parts of the libraries from the portable ones b) 
Introduce a finer package granularity in general. While I think that a) is a 
worthy goal, I think that this will be very, very tricky due to the fact that 
different Haskell implementations have quite different notions of builtins, 
extensions, etc. Furthermore, I am not yet fully convinced that the resulting 
structure will be vastly superior regarding readability and maintainability, 
sometimes some simple CPP tricks are the lesser evil. Regarding b): As 
already mentioned above, there is always a tension between the ease of 
upgrading and testing. Furthermore, we should not abuse the package system to 
get versioned *modules*. Anyway, let's not mix a) and b)!

 * It is silly to split a data type like FilePath and the only portable 
operations on it into different packages. Let's put the file path handling 
operations whereever FilePath lives, and this is "base" in the foreseeable 
future. Discussing if FilePath should belong into "base" is a different 
topic.

Cheers,
   S.