Announce of Core (ghc-base) library

[Bulat Ziganshin]

This message is of primary interest for developers of Haskell compilers and
core libraries. it duplicated at http://haskell.org/haskellwiki/Library/Core

Thanks to Cabal, now we can easily upgrade any installed library
to new version. There is only one exception - Base library that is closely
tied to compiler internals, so you cannot use Base library shipped with
GHC 6.4 in GHC 6.6 and vice versa.

The Core library is a project of dividing Base library into two parts -
small compiler-specific one (the Core library proper) and the rest - new,
compiler-independent Base library that uses only services provided by Core lib.

Then, any version of Base library can be used with any version of Core
library, i.e. with any compiler. Moreover, it means that Base library
will become available for the new compilers, like yhc and jhc - this
will required adding to Core lib only a small amount of code
implementing low-level compiler-specific functionality.

Core library consists of directories GhcCore, HugsCore... implementing
compiler-specific functionality and Core directory providing common
interface to this functionality, so that external libs should import
only Core.* modules in order to be compiler-independent.


In practice, implementation of Core lib became a refactoring of GHC.*
modules by splitting them into GHC-specific and compiler-independent
parts. Adding then implementations of compiler-specific parts for
other compilers will allow us to compile refactored Base library by
any compiler including old versions of GHC. At this moment, the
following modules was succesfully refactored: GHC.Arr, GHC.Base,
GHC.Enum, GHC.Float, GHC.List, GHC.Num, GHC.Real, GHC.Show, GHC.ST,
GHC.STRef, and the next step is to refactor IO functionality

Like the original GHC.* modules, Core library builds up its
functionality in layers, where each next layer use features provided
by previous ones. Already written layers are, in order of dependencies:

Base
Integer
Integral
Float
ST/Int/Word
Arr

Each layer includes both compiler-specific and compiler-independent
modules, say first layer is represented by GhcCore.Base/HugsCore.Base
and Core.Base modules

in contrast to initial design i proposed, compiler-dependent modules
in each layer can import and use compiler-independent functionality of
previous layers, this greatly simplifies writing of compiler-dependent
code and allow to avoid code duplication. For example, GhcCore.*
modules widely use && operation defined in Core.Base module. So, when
compiling with GHC, dependencies order will be as follows:

GhcCore.Base -> Core.Base ->
GhcCore.Integer -> Core.Integer -> ...

at last end, this mean that Core library can't be split to GhcCore,
HugsCore and other separate ones, but need to be united library that
includes code for all compilers we support

speaking in terms of versions, Base and other higher-level libraries
can request specific Core version (say, 2.0.*) and be sure that some
set of services should be available. Inside these version range, Core
library may grow to support additional compiler versions, say only GHC
6.6 in 2.0.0, GHC 6.6/6.8 and Hugs 2006 in 2.0.1 and so on


Why i stopped further development of Core at this stage? First, it was
not so hard task - in a week or two i've refactored, afair, 1/3 of GHC.*
code. My next goal was to implement Hugs support for all already
implemented facilities, but i find serious problems with redefinition
of Prelude types and classes. may be, using a feature of upgrading
Base, this will become no problem. The same problem, although in less
degree, i had with GHC too

Second problem that stopped me was I/O part of GHC.* library. It seems
impossible to move this out of Core (!) library because Handle type
used in definition of Exception type which used by 'fail' for IO Monad
and IO monad used everywhere. so, we need some brainstorming to analyze
the situation and general tendency of Base library to use too many
dependencies. One example was provided by Ross: Data.HashTable is used in
Data.Dynamic, that is used in Exception.. so, again, it can't be
moved out of Core lib!

but even if we can't extract Core library from Base as
"compliler-equalizer" subset of modules which includes only Core.* and
don't includes Data.*, System.* and other code, at least it's possible
to split existing GHC.* code into simple compiler-dependent and more
complex compiler-independent parts and simplify way to support

1) new compilers like JHC and YHC
2) range of compiler versions instead of just one version

so, i hope that this work will be interesting and helpful for
community, especially in order to help new compilers support rich set
of libraries with a minimal effort

library is available as http://www.haskell.org/library/Core.tar.gz
please note that Data.* modules should be considered not as part of
library but as examples of modules from future Base library that will
be based on services provided by Core


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