Hi Twan,
I think this is already being done to some extent - so things that GHC
ties to closely are being moved out of base. See this wiki page:
http://hackage.haskell.org/trac/ghc/wiki/PackageReorg#Implementation-specifi...
Thanks
Neil
On Fri, May 16, 2008 at 1:14 AM, Twan van Laarhoven
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 _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries