On Thu, Jan 25, 2007 at 06:18:01PM +0000, Neil Mitchell wrote:
Maybe if we had a greater number and variety of optimising compilers we'd be able to more freely experiment with optimisation techniques in different settings. At the moment GHC is all there is (with Jhc not ready for mainstream use yet)
Jhc has recently gotten a ghc back end, making it much closer to mainstream use as an optimizing 'front end' to ghc. In addition to some of jhc's crazy optimizations, it implements several extensions to the language which will likely prove interesting to play with to some. I would really welcome any volunteers who would like to help develop the ghc back end while I work on improving the grin back end and optimizations in general. There is now a mailing list for jhc at: http://www.haskell.org/mailman/listinfo/jhc I think one of the reasons jhc has been so slow to reach mainstream usability is that there aren't many eyes looking at it. When I work on it, my eyes tend to be very focused on the task at hand, which is likely some obscure optimization and I might not even notice for weeks if something basic like package support breaks or if a basic class instance is missing from the libraries. Besides me, Einar Karttunen has been the only other major developer but I would love it if more people wanted to help out, or just poke around. Simple things like filling out the libraries, or noticing where the front end isn't reporting an error it should or typing things incorrectly or working on the ghc back end could be done without knowing a lot about the internals of the compiler. Another good but bigger project (though it would take a lot more knowledge of the jhc source than the above) would be separate compilation support, there is no reason it couldn't work with the ghc back end, but one would need to add some infrastructure for actually spitting out partially compiled modules and calling ghc etc... And of course, new backends would be great. I have infrastructure built up for .NET, it parses and passes through hugs .NET compatible foreign declarations through the compiler so all that is needed is the final code generator and modifying some of the libraries to make the appropriate .NET calls instead of C ones. Basically, all that is needed is a module to convert jhc core (effectively equivalent to ghc core and system F) to .NET as all the front/middle end stuff is in place. John -- John Meacham - ⑆repetae.net⑆john⑈