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

[Bulat Ziganshin]

Hello Simon,

Wednesday, October 4, 2006, 5:00:25 PM, you wrote:

> | 'c' syntax creates GHC.Base.Char instead of Char
> | [a..b] requires instance of GHC.Enum.Enum

> What do you think needs fixing?

using types and classes that are in scope, of course. i have several
more examples but because it's not required for me nor important for
you, i will put them all into a ticket. ok?

> GHC's flag -fno-implicit-prelude
> currently means two things
> a) don't import Prelude
> b) use rebindable syntax

> Now (b) is not fully implemented, as you found, and there are other
> examples.  E.g. guards use Bool, which is GHC.Base.Bool, not the Bool
> that's in scope.

moreover, guards are desugared into monads, that was a bit surprising :)

my attempt to refactor base library without recompiling entire GHC was
breaked by these restrictions. so now i import genuine GHC.Base and
then make my development on top of it

what is the simplest way to experiment with my own version of base
library? can it be accomplished without recompiling entire GHC?

> If what you want is to move Char from GHC.Base to some other module,
> then we can easily teach GHC about the new location (I can tell you how
> to do that).  That'd be much easier than the rebindable syntax thing.

> It would indeed mean that you could not use the new lib with an old
> GHC... but GHC and its base library are pretty closely coupled.  They
> are gradually getting less coupled, but I doubt we can eliminate
> coupling altogether.

guess, that i'm trying to do? ;)  is it possible to define, say, Enum
class in module Core.Base and then import this module in GHC.Enum?
this will make circular dependency - usage of Enum instances in
Core.Base will be resolved via definition in GHC.Enum while this
will import for definition Core.Base. but this scheme will allow
compatibility with existing GHC versions that is a big plus. so can it
work?

> | 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

> But GHC's organisation evolved over some time, and we reorganised
> several times after discovering "gotchas".  You mention some of them ...
> but read the library organisation notes at the top of GHC.Base.
> Getting the organisation to work wasn't all that easy -- and you have
> more constraints than we did (notably, supporting multiple compilers).

these notes are my Bible now :)))  i hope to make all these modules
Hugs-compatible in a few days

> In short: good project, but maybe a bit of a thankless task.  I'm not
> 100% sure it's worth the bother.

shortly speaking, in ideal goals are:

1) make base library compiler-version independent
2) include support for other compilers (yhc and jhc) and make cheaper
"entry ticket" for any new compilers
3) stop replication between compilers of almost the same code for base
classes and their instances. it will be nice to have only one instance
of this code and may be this can help H' committee

> It might be easier to specify a "core
> prelude" that is implemented differently on each compiler, and then have
> a compiler-independent libraries built on the core.  That is why there's
> a sub-directory GHC.  Each compiler can have its own sub-directory; but
> each of these compiler sub-directories implements the same interface.
> That would be my suggestion, but I have not been following in detail

if mountain don't walk to Magomet then Magomet can walk to mountain :)
i mean that now yhc and jhc compilers are don't implement existing
"core prelude" interface so one can try to help them

this project may be considered as a next step of simplification of the
"core prelude". i hope that this will also help to reach other goals
mentioned

and refactoring (mainly boxifying) of existing GHC.* code turn out to
be very easy. just now i'm close to compilation of Base, Show, Enum, Num and
Real modules with Hugs. i'm hope that in case of success you will
consider replacing current GHC.* with these modules, but anyway i have
at least one "customer" - Neil :)

and while we are here, can you please answer several questions?

there are several definition that use c@(C# _), like this:

    jhead n cs
        | n < 10    = case unsafeChr (ord '0' + n) of
            c@(C# _) -> c : cs
        | otherwise = case unsafeChr (ord '0' + r) of
            c@(C# _) -> jhead q (c : cs)
        where
        (q, r) = n `quotRemInt` 10

i guess that it is for strictness and can be replaced with calls to 'seq':

            c -> c `seq` c : cs


There a few of Float/Double-related RULES in GHC.Base:

{-# RULES
"plusFloat x 0.0"   forall x#. plusFloat#  x#   0.0# = x#
....

Why they are here - by mistake or it has some sense?


-- 
Best regards,
 Bulat                            mailto:Bulat.Ziganshin at gmail.com