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@gmail.com