Proposal/Idea: Split up base even further

Twan van Laarhoven twanvl at gmail.com
Thu May 15 20:14:02 EDT 2008


Hello librarians,

Here is an idea to resolve some of the problems that remain with the base package:


The problem:

Users can not update their version of the 'base' package, since it is tied to 
Ghc. If a useful new function is added using it requires updating the compiler. 
On the one hand this puts people off using these new functions. On the other 
hand it also makes updates to for instance Data.List take way longer to reach 
the users because we have to wait for the next Ghc release.


The proposal:

User code should NEVER import the library that is now called 'base', it should 
provide an internal API only. For example, base can include the modules
      Internal.Data.List
      Internal.Control.Monad
      Internal.IO
      etc.
Which are as minimal and low level as possible, containing just the things that 
Ghc RELIES on like:

   - type classes for which instances can be derived (Eq, Ord, etc.)
   - data types and classes with syntactic sugar (Bool, [], Num, Monad)
   - low level stuff like IO and ST and primitives

In short, everything that is now under Ghc.*, and hopefully less, becomes the 
new base library. In my opinion half of that can still be moved out, like most 
of Ghc.List, Ghc.Enum, Ghc.IO and Ghc.Read.

The next layer can then consist of many packages like "containers", "control", 
"numeric", "concurrent", "ioref", "file-io", "foreign", etc. For example the 
Data.List module imports Internal.Data.List for the basic list data type. It 
re-exports this, and adds many additional functions that don't belong in the 
minimal base library.



Thoughts?


Twan


More information about the Libraries mailing list