base libraries

[Bulat Ziganshin]

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