[Haskell] base libraries

[Bulat Ziganshin]

Hello Simon,

Monday, November 27, 2006, 1:38:27 PM, you wrote:

>>>However, it's highly unlikely that you'll ever be able to separate
>>>ForeignPtr from the base library, because of the dependencies:
>>>ForeignPtr is part of the FFI, the FFI is used by other libraries, etc.
>>>etc.  The dependencies in base are very intertwined, as you well know.

FPTR representation was changed ghc 6.6 Base - now it includes Addr#,
which makes things a lot faster. is it technically possible to do the
same thing in ghc 6.4? yes. it don't require any changes in compiler -
FPTR type is not primitive (like Addr#, f.e.) and not wired into
compiler. can we do it on practice? no. what is the problem? we should
be able to compile new Base library with 6.4 and install it here

now, with 6.6 we can install alternative Base implementations. but
only in theory - there are no such alternatives, and situation is the
same (now) for ghc, hugs and nhc. next step is to make Base library
portable across compiler versions. i.e. Base 2.0 should be compilable
with ghc 6.8, and Base 2.1 should remain compatible with 6.6. the same
for hugs/nhc. if we will do it, then this aspect of problem will be
solved on practice. this would simplify upgrading/downgrading compiler
version for large projects and allow to combine features of newest
Base with stability of older compiler

is it possible to have several Base installed at the same time so that
Cabal expose only version requested by .cabal file? in ghc/hugs/nhc?

>> Ah, so how do the other compilers manage it?  Answer: Hugs has a
>> separate package 'hugs-base' with essential but implementation-dependent
>> things like ForeignPtr in it.  (Likewise nhc98/yhc.)  The 'base' package
>> just imports and uses it.  If we could separate out a 'ghc-base' package
>> from 'base', that would be great.  (And I think that is one of Bulat's
>> proposals.)

> As I understand it, Hugs and nhc98 do this by having their own copies of a lot
> of the library code (up to and including the Prelude?).  We could do this for
> GHC, but it would mean extracting a lot of code that isn't really GHC-specific
> into ghc-base, and that doesn't seem like the right way to go.

ghc does just the same :)  Hugs Prelude and ghc.* modules has many
common code, from 'const' to showFFloat

> So there are two approaches to reducing the size of the base package:

>   1. removing modules from the top into separate packages
>   2. try to extract a compiler-dependent portion from the bottom

> (1) is way, way easier than (2), because of the heavily intertwined dependencies
> between the code underneath Prelude.

we should go in both ways, definitely! Base is too large *and*
compiler-specific, at the same time. we should reduce it by splitting
to more specific packages and we should isolate compiler-specific code
from compiler-independent. so, it will be great (if possible) to split
off smth like ghc-base, and we should work on moving more code into
separate packages 

> That's unfortunate.  Bulat did start to
> try to separate things this way, but he didn't finish (Bulat - did you give up
> because it was too hard, or just stop?).

both :)  it was too hard for 1-2 week project. i will report its state
and potential problems here

> In the wiki page, we describe how to get part of the benefit of (2) as far as
> the user is concerned, by having a separate "view" of the base package with the
> compiler-dependent modules removed.

believe it or not, but i think that we need just opposite view :)  the
problem is not to make ghc.* inaccessible, the problem is to make
inaccessible the rest! :)

why? let's imagine that Control.Monad in ghc 6.8 was extended with
function repeatM_. how it can be used in 6.6? one need to write some
library that provides new version of Control.Monad with this function
included. but it's impossible to export such module - it will
interfere with module from Base. and it's impossible to remove this
module from Base because it's used in Prelude. so, it should remain in
Base, but used only by Base itself!

so, one more possible approach is to rename all Base modules to say
Base.* and export from Base only GHC.* (and closely related)
functionality. Then another package will import GHC.* and provide all
other Base functionality, but its code will be compiler-independent
and therefore easily upgradeable

of course, it also not so very good - 1) code duplication, 2) wired-in
things should be imported from original definition places, but at
least i showed up the problem. and the problem is the following: our
compiler-dependent code use a lot of higher-level code. if we want to
be able to freely upgrade higher-level code without modifying
lower-level one, we should leave a copy of old high-level code to be
used only in low-level code and hide this copy from the rest of world
(or use library versioning mechanism, but it seems inappropriate due to
huge number of low->high->low dependency jumps)

and Haskell Prelude sitting on top of this problem :)  i'm right
assuming that Prelude can't import anything outside of Base? this
means that Base should include everything, from I/O to text parsing



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