core lib attempt#2: problem with hard-wired module names for classes in GHC

[Bulat Ziganshin]

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