GHC supports concurrency, exceptions, weak pointers, foreign calls, etc, etc. All these need to be mapped onto .NET. ... GHC comes with a large collection of libraries of its own. These need to be still available in the .NET version.
I don't really agree with these points. If someone tried to support all of this they'd be unlikely to appear out the other end of the swamp. Having actually tried both ways myself, I'd suggest that GHC is simply not the right starting point for a Haskell.NET compiler. Much better to start a fresh compiler, essentially from scratch, with a suitable selection of optimizations, language extensions, library features and interop extensions given the platform and kind of programming you're aiming to support. If you look at history successful compiler projects do not tend to some out of attempts to graft large code bases for alternative purposes (unless you've got loads of resources to throw at the problem). Cheers, Don -----Original Message----- From: Simon Peyton-Jones [mailto:simonpj@microsoft.com] Sent: 31 May 2002 15:31 To: Don Syme; D. Tweed Cc: Paul Hudak; haskell Subject: RE: [Fwd: F#] | Idle curiosity: which aspects of the Haskell language are the | ones that make it complicated -- e.g., long-time stuff like | lazy evaluation, typeclasses & inferrence, etc or newer stuff | like functional dependencies, etc or something else entirely | -- and do they only make it complicated in the context of the | .NET architecture or in any implementation? General remarks about targetting .NET from GHC. * There is no reason in principle why one can't write a back end for GHC to generate .NET IL. * Generating *verifiable* IL is noticeably harder: you have to take much more care; to deal with parametric polymorphism you need Generic IL, which isn't "out" yet; and even then, higher kinded type variables are a serious problem. Being verifiable almost certainly requires some runtime checked type casts, which hurt performance -- and reducing them to a minimum complicates the compiler. * My conclusion: best plan is to generate unverifiable IL, and run it unverified. Situation is then just like an existing code generator: you have to trust the compiler. But it's fast and it's much simpler. * The resulting code will still run quite a bit slower than GHC-complied code. So why would anyone want to use it? Presumably, to get access to the .NET libraries. So that has to be very convenient. Tools are needed to read .NET library meta-data and generate impedence matching glue to make them easily callable from Haskell. Haskell needs some new 'foreign import' stuff to make it easy to call the libraries. There's a big design space here about how much to extend Haskell to make calling .NET convenient. * GHC supports concurrency, exceptions, weak pointers, foreign calls, etc, etc. All these need to be mapped onto .NET. Some might not fit well; for example, Concurrent Haskell assumes extremely lightweight concurrency, whereas .NET threads are OS threads; and asynchronous exceptions might be tricky too. * GHC comes with a large collection of libraries of its own. These need to be still available in the .NET version, so the .NET implementation of GHC needs to be pretty fully-featured (because the libraries use a lot of features). What all this means is that GHC.NET is a lot more than just a code generator. That is, I think, what Don meant when he said that GHC is complicated. (In our defence, it is the very fact that GHC is a rich system that makes it useful. Its complexity is not gratuitous.) Part of my reason for writing this is to encourage anyone out there to take up the challenge. There's nothing too difficult -- it's "just work". Simon and I don't have immediate plans to do anything about this, but we'd be delighted if someone else did. Congratulations to Sigbjorn to doing a great job with Hugs. Simon _______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell