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