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

[Bulat Ziganshin]

Hello Neil,

Friday, September 15, 2006, 8:12:34 PM, you wrote:

> [Moving to cafe for follow up discussions]

i should be started this discussion in libraries... :(

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

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

> The leveler:

> Core - which abstracts each version/variant of *.Core into one big
> pile. Contains versions of STM/Arrays in Pure Haskell which might not
> give the expected performance, but at least keep the semantics as best
> they can.

Core - provides common API
*hc-core - implements strict subset of this API
Core, again - checks compiler brand and version and either imports
appropriate module or emulates required behavior

So, the *Core and Core has the same API, although each *Core defines
only subset of these names. it's why i called Core "equalizer" - it
adds unimplemented "rights" to the "poor" Haskell compilers :)


> Base:

> Pure Haskell which depends on Core, but NOT on *.Core.

yes, keeping in mind that *Core APIs are subsets of Core API


> I think this is a great plan! Now you have a concrete idea of what you
> want to achieve in the end, how are you going to get there? It seems a
> rather ambitious project.

> Perhaps you might be best suited by getting base to compile with Cabal
> (and maybe even natively on Windows - without MingW), then you can go
> from there to the splitting in a Cabal friendly manner without hacking
> through makefiles?

Igloo just wrote that he changes the 'base' to compile with Cabal (i even
don't known that it don't works). To be exact, i propose some
algorithm of doing it in a way that should allow

1) work over existing 'base' repository, so we don't end with two
libraries to maintain in-between
2) make the changes in small steps, don't breaking anything in-between
3) allow to participate all the 'base' hackers

if it will be possible to work with modified 'base' library as with
any other package, without rebuilding the GHC itself, i will make
some contribution to this work. as i said, i have great experience of
developing portable software

> Anyway, once you have decided what you want, I'm sure the Yhc team
> will do their best to help you get to where you want with regards to
> that specific compiler. Just to try and keep your work more generally
> applicable, it would be nice if you kept the Hat project in the back
> of your mind, so that this work can be reused by them to get full
> haskell.org libraries.

first - i propose to do a series of incremental rewrites of existing
base package, i never mind to do it from scratch :) second - are you
sure that Hat needs to work over core libs? all that these libs should
contain is just a lots of trivial definitions like this:

type Arr = Arr#
newArr = newArray#
.....

third - you can point to the guidelines of writing Hat-comptaible
libraries so that we will know how to write right code. as i said,
developing of basic libs is easy in terms of algorithms but a pain in
terms of lot of requirements from many various sources

about yhc - hopefully, current base lib don't supports it. ensuring
compatibility with ghc, hugs and nhc during transition will be a hard
problem by itself. but once transition will be completed,
implementation of yhc.core library should be very easy, especially
using nhc.core as a start point. that you can do to help us is to provide
list of differences between nhc and yhc low-level libraries so that we
account for these differences when developing Core API


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