base libraries

[Simon Marlow]

Bulat Ziganshin wrote:

> libraries should be split into 4 rings: frozen, core, base and the rest
> 
> * frozen libs are installed with haskell compiler and cannot be
> upgraded using Cabal. it includes Cabal itself and libraries required
> by Cabal, currently it's the Base library. compiler may provide its
> own ways to upgrade these libs
> 
> * core libs are tied closely to specific compiler and version.
> therefore, these are also preinstalled but can be upgraded with Cabal.
> in order to make upgrading not-a-headache, version of such library must
> include compiler version, i.e. TH 6.6.0. for ghc these currently
> includes TH and STM libs
> 
> * base libs are *guaranteed* to be shipped with any haskell compiler
> (compliant with this proposal). these libs are installed using Cabal
> or OS package manager, only on poor Windows-like systems these should be
> included in monolithic compiler distro. the reason is to allow user to
> got latest, bug-fixed versions of these libraries for the installation
> moment

Please let's not change the terminology again.  On the wiki page we use the term 
"Core libraries" for the set of libraries shipped or available on all the 
compilers.  I don't see a good reason for naming any more sets of libraries, so 
can we just keep things simple?

> haskell98, readline, unix/Win32, QuickCheck, fgl, haskell-src, html,
> mtl, network, parsec, time, xhtml,
> ByteString, regex-*, Edison, Filepath, MissingH, NewBinary, arrows,
> HUnit, QuickCheck, monads

So you want to have two variants of monad infrastructure, mtl and monads?  How 
does the user decide which one to use?  Two variants of HTML infrastructure? 
Why Edison rather than any other data structure framework?  One particular 
non-portable line-editing library?  Some of these choices seem entirely arbitrary.

When there's an overlap and no clear choice, usually the right thing to do is 
let the user decide.  At least until a concensus emerges.

We have an effective mechanism for proposing library changes now, so I suggest 
that the Core libraries should start small, and then expand via proposals.  That 
way we get to discuss additions one at a time, rather than throwing the kitchen 
sink in to begin with and having to argue about what to remove later (and 
upsetting users when we do remove things).  This way We end up with a more 
consistent, well-design, whole.

Cheers,
	Simon