Hello glasgow-haskell-users, i'm now trying to rewrite GHC.* in more portable fashion, "boxifying" all the definitions in hope that smart compiler will unbox them itself of course, i'm using -fno-implicit-prelude and have found some more things that still hard-wired into compiler: 'c' syntax creates GHC.Base.Char instead of Char [a..b] requires instance of GHC.Enum.Enum it will be great to fix this (i will make ticket), but that is not show-stopper the problem that i'd imagined is how this new cool base library can be used with existing GHC version? of course, users will not use -fno-implicit-prelude, so their apps will expect that Enum class is defined in GHC.Enum and no other place. or it can just re-export class defined in some other module, say Core.Enum? even more problems with GHC.Base mpdule which should define both some hard-wired types and classes what means that we can't move out of this package some intermediate code (at least, without using recursive modules) about core library attempt#2 - the main problem in bootstrapping Haskell libs (for any compiler) is the expressiveness problem - for example, in order to define "instance Show Int", you need to use '/' operation which is defined in Integral class that in turn requires Show instance. GHC solves this problem by omitting use of classes in low-level modules and switching to the # operations. this perfectly works, but don't compatible with other compilers. what are other possible solutions? 1) lift all the # operations to the corresponding operations on boxed types and change low-level modules so they work with these un-classified but boxed operations, so the following: GHC.Base: divInt (I# a) (I# b) | gtInt# a b = mulInt# a b turns into: GHC.Base: gtInt (I# a) (I# b) = gtInt# a b mulInt (I# a) (I# b) = mulInt# a b Core.Base: divInt a b | gtInt a b = mulInt a b 2) another solution is to bring together definitions of Show/Enum/Num/Integral classes and their Int/Integer instances in one large module. after all, by the limiting it to only Int/Integer instances, its size should be reasonable. This will allow to use "natural" definitions (i.e. use '*' and '>' operators), although i fear that this can produce slower code. in particular, this can create circular dictionary dependencies (i.e. Show Int instance depends on Num Int and vice versa, which, according to my experience, prevents inlining of all methods (!) in both classes; although my experience was with parameterized instances (i.e. like Show [a] <=> Num [a]), so may be it will be not a problem here) it seems that integer literals in Hugs completely don't work before introduction of fromInteger operation. so it seems that the second way is the only really possible one :) it will be great to hear critics before i will invest time in implementing second plan. as a first result, i plan to refactor GHC.Base, Show, Enum, Num, Real modules into somewhat implementing the same facilities but compatible with Hugs. i think that this will make a solid foundation for future co-development of core lib -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com