base libraries

[Bulat Ziganshin]

Hello libraries,

current situation when Base lib includes everything, from 'const' to
starship control, creates serious problems for upgrading to next GHC
version. this problem arise because every GHC version arrives with its
own, non-upgradable version of Base library and even minor API changes
here results in total loss of ability to use new ghc version without
#ifdef workarounds 

it seems strange, but even in this situation some developers prefer to
include their modules in base lib instead of providing them as
separate libs that can be easily upgraded using Cabal so that any
library version can be used with any version of ghc

after analyzing the situation, i concluded that source of problem, at
least partially, is GHC HQ's policy of packaging libraries with GHC.
The list of such libraries is *closed* and odd at first look. why, for
example, it includes 2 of 4 regexp libs? at last end, we can learn
that this is the list of libs required to build ghc itself!

unfortunately, ghc building process don't require FilePath or ByteString
support. this results in situation when authors of these libs, looking
for a way to include their libs in every ghc distro, don't find other
solution except for including them in Base lib. moreover, while Simon &
Ian argued against inclusion of these very useful libs in base libs
set, they don't have anything against inclusion of the same code in
Base lib 

i'm all for docracy, but not in this case. having the experience of
patching the program after each ghc upgrade, and having a bunch of
conditionally compiled code in my libs, i can easily imagine ghc
version hell that these new modules will provide for us

so, i think, it is time to revise ghc libraries policy. i propose to
split libs into the 3 "rings": core, base and other

* core libs includes ghc version dependent libs. currently it's base,
stm and th

* base libs are libs, which is guaranteed to be shipped with *every*
haskell distribution. on windows, it should be a part of monolithic
installer while on unixes these libs may be a separate packages, but
porters should ensure that they ported all these libs too

this set should include only small and widely used libs, what is
mainly datastructure processing ones. my current list includes
regexps, bytestring, filepath, time, mtl, fgl, newbinary and so on

* other libs are either too specific or too large, such as gui,
database and xml ones. these may be included in some distros or
installed separately

these rules don't say anything about ghc self-building process. it
will be great to maintain the list of libraries, required to do it,
separately


and while we are here - splitting of Base library should be very easy
task. its ghc version specific part is in GHC.* modules. these modules
should be moved into the new Core library. plus a few modules from
Data.* or System.* hierarchy they imports. plus a few modules imported
by Hugs/NHC Prelude. the rest of Base library should be pretty portable, at
least between various GHC versions.

and independent on this work, we can always look into moving pieces of
Base into independent libs. as a rule of thumb, everything not used in
Base lib may be moved outside of it. of course, these new libs should
be included in base libs set

in particular, my hottest hope is that ghc 6.6.1 will be shipped with
fps 0.8 as separate library that will provide both backward
compatibility with 6.6 and will allow to upgrade fps without recompiling
ghc itself :D

-- 
Best regards,
 Bulat                          mailto:Bulat.Ziganshin at gmail.com