[Haskell-cafe] Re: [Haskell] Re: compiler-independent core libraries infrastructure

[Bulat Ziganshin]

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