compiler-independent core libraries infrastructure

[Bulat Ziganshin]

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