Hello John, (i'm moving thread to the ghc-users where this discussion continues in ghc-related aspects) Thursday, September 28, 2006, 3:30:09 AM, you wrote:

...

So, just to confirm in my mind what you are proposing:

Compiler/Version specific Core:

Yhc.Core, Hugs.Core, GHC.Core ....

With a different version for each compiler version. Tied intimately to the compiler.

A large issue with this, is that what needs to be tied intimately to the complier is very different for different compilers. for instance Data.Typeable and Data.Dynamic are fairly portableish haskell on ghc, but are primitives provided by the compiler in jhc as a very simple example.

module JHC.Dynamic: .... module Data.Dynamic: #ifdef JHC import JHC.Dynamic #else -- make portable definitions #endif in general, compiler-specific code should go into *hc-core libraries while the "default implementations" into the common core package i have experience of multi-OS development. it is not the solution to write program tied to API of some OS or two and then make complex translation layer for all other OSes. instead, i select the common subset of APIs and try to use only it. if that's impossible, i make the translation layers that gives OS-neutral names to common functionality and masks OS-specific details

It leads to the current mess with the jhc libraries where it has bits and pieces of base. I can't just use base as is, because it implements a lot that jhc needs to implement natively or expects things that GHC.* provides, but Jhc.* doesn't, or at least provides with a different interface/semantics (and #ifdefs or tieing jhc's development with the fptools repos are not acceptable solutions) However, a lot of stuff depends on libraries provided by base, so I can't just ignore it.

so I end up syncing some code from base, modifying some, having a big mess that is somewhat tricky to maintain.

yes, jhc will get the largest benefit if this project succeeds - and even partial success will mean that jhc may get some better libraries than now. i don't imagine that i can develop some theoretical scheme in which each compiler will fit - vice versa, the plan is to look at all the compilers that are worth to support (now it's ghc, hugs, nhc, yhc and jhc) and realize what the common API for all them may be. if support for one more original compiler will be added in future to Core then API may need to change again.

In any case, haskell-prime will clean this up some by giving a more complete compiler-provided set of libraries, and it looks like the fptools repos are moving in the right direction with modularization.

i don't understand how H' will help jhc - with any library report you will need to implement it yourself :) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com