Hello Ian, Friday, September 15, 2006, 8:20:36 PM, you wrote:
what is a 'base' library now? it is the library that implements common set of operations for latest versions of ghc, hugs and nhc. it contains low-level implementation for ghc, but relies on separate hugsbase package for hugs (the same for nhc, afaiu). so, first step is obvious - separate ghc-base library from the rest. hugsbase, ghc-base and nhc-base packages should provide common set of low-level operations,
As it happens I was working on getting GHC to use cabal to build base et al on the plane the other day, and I had a brief look at this. Unfortunately there is a tangled web of dependencies, e.g. you need the low level Int# stuff in ghc-base, then Int in base, but then any other GHC-specific stuff can't use Int because it's in base. We could put everything into ghc-base and just re-export the common stuff in base, but then we can't share any code between ghc, hugs etc. I haven't looked in detail to see just how bad the problem is, but I agree it would be really good if we could split things up somehow so that base (or whatever base gets split into) is the same everywhere.
yes, it is one of problems that i was overlooked (and i expect that discussing my plan will show other problems i skipped by ignorance) first, let's specify that i propose (my today letter in haskell list contains more detailed plan): ghc-base should export Int operations. why? because it can't export Int# operations, they are not supported by other compilers (as the whole "unboxed type" concept), so they are useless to export. 'core' library should provide some common API. *hc-core libs should provide _subset_ of this API with hope that 'core' will emulate missing features but problem your mentioned still remains - while ghc-base defines operations on Int, it don't contains class Num definition, so that (*) or (+) operations can't be used. so that can we do? we should use intMul, intAdd and other operations directly. we can even define (*) and (+) operations for _internal_ use inside our ghc-base package, but not export them. while this seems a little Draconic, it will allow us to share Num defining code with other compilers and even introduce libraries with alternative Num/(*) definitions while idea of using some internal (*), (+) ... definitions may seem like work duplication, my experience says that it's much better to define duplicate operations for internal use only rather than try to implement whole Num class inside each compiler-specific library - because this definition should be a high-quality code and we don't want to copy such code over and over again and i hope that *hc-base libraries will not use Num operations too much because their main purpose is to give standard interface to compiler-specific functions, not to implement any algorithms. for example, looking to GHC.* modules in my own ArrayRef lib (which implements boxed and unboxed arrays), i don't see any arithmetic in _process_ of rewriting base lib, we should not have problems with GHC, because we can use recursive imports. but in order to retain compatibility with Hugs we may need to move Hugs.* modules inside 'base' package (the same for nhc). well, i don't know the best plan for intermediate versions. one possible but slow variant is to introduce intAdd/... operations, then rewrite ghc.*/hugs.*/... using these operations, then move out non-core stuff and then rewrite it back... -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com