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.