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:[EMAIL PROTECTED] _______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
