Hello Jeffrey, Sunday, March 18, 2007, 6:38:11 PM, you wrote:
try to compile base of ghc 6.6 using 6.4 compiler and vice versa. 6.8 is not yet finished, so i guess that differences between base 2.0 and base 3.0 will be much larger that now
That's inconvenient but not a fundamental problem. Say ghc-6.8 gets up to base-3.2 by the time 6.10 is released depending on base-4.0. Then someone wants to add System.ZOMGio to base. They add it to both base-3.3 and base-4.1. Someone who wants to use it needs to specify that they depend on base ">=3.3&&<4.0 || >=4.1", and can probably assume that >>=5.0 will also include it.
of course, this *can* be done. the problem is that it is hard to do, so it is not done. and changes between base versions also include changed interfaces, for example MArray class was changed in 6.6
So, to solve the immediate problem you're complaining about, it might be more practical to pull the "bottom" (GHC/Prim*.hs) out of base into something like ghc-prim for ghc-6.8 rather than to prevent new modules from being added to the top. Then base can be refactored at a more leisurely pace.
look at http://haskell.org/haskellwiki/Library/Core :)
You're depending on the existing base package from these files.
yes, but i tried to do it in that way that omitting Base dependency will be easy. ghc.Prim, btw, is pseudo-module, whose "contents" are generated by compiler automatically from primops.txt.pp Core library is a first try to split GHC.* modules into ghc-specific part (which is not limited to GHC.Prim) and the rest. Ultimately, Core library should include compiler-specific code for several compilers (ghc, nhc, hugs...) and additional code that simulates features omitted in some compilers (arrays, for example). Core library should export API which is the same for all compilers and compiler versions and then Base should import Core and therefore become compiler-independent. so, it just the same plan as your own -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com