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