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

[Simon Peyton-Jones]

| 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

What do you think needs fixing?   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.

It would not be easy to make everything rebindable; and I am not sure
why you want to for this project.

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.

Simon

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

In short: good project, but maybe a bit of a thankless task.  I'm not
100% sure it's worth the bother.  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

Simon