Hello Sven, Friday, November 24, 2006, 11:32:35 AM, you wrote:
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!
this problem may be solved by versioning policy (or police :), i will write a separate letter about it
* 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.
i think that you just not enough involved to see complaints about impossibility of using new features in old projects
* Bulat wants to do several things at once, if I understand it correctly: a)
no. i discuss several things at once, because Neil thinks that these things must be done at once. But as i said in each letter, we don't need to wait major splitting of Base library to start development in new way. problems he mentioned may be solved just by inclusion FilePath into the set of base libs, and it's very easy change
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.
i'm not purist and don't propose to do something supernatural. my plan is just to split base at the natural bound (ghc.*) and look how this can be made more portable by moving parts of code between two splitted parts
* 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.
of course, it will be much better to move all I/O stuff from Base into separate package. that's impossible, though, because: 1) Prelude needs readFile and other I/O operations that can be imported only from Base (afaiu) 2) "instance Monad IO" defines 'fail' for I/O monad which uses Exception type whose definition involves Handle i think that these two problems shows "monolithic design" problem of Haskell itself, but while we should live with it, it should not force us to put everything Prelude-related into Base. naturally, FilePath type should belong to Files package, not amorphous and non-upgradeable Base. while we can't do it, we should at least put any other functionality here, again, while "put the type and its functions together" is a nice theory, practice, in this case, shows that 1) FilePath type never mind to change itself :) 2) Base is non-upgradeable which creates real problems for using functionality included here -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com