| 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