Sigbjorn has already shown how a non-IL-generating approach is possible. I think a simple implementation of a Haskell.NET compiling to IL is feasible, especially if you're willing to do the interop with .NET components by extending the language as with F# or SML.NET. It's more that GHC is a bit of a complex point to start from. Of course doing a full Haskell implementation from scratch requires an intimate knowledge of all the features you mention, and is the sort of thing one only tends to get right on the second or third time you do it. And getting top-notch performance is obviously always a huge challenge for Haskell, and you can't play some common implementation tricks when compiling to IL. But the only truly serious complications added by .NET itself are (a) the general problem of Haskell interop with imperative libraries, requiring you to reach for monads quite often (or to wrap the libraries yourself) and (b) the well-known problems of combining type inference, subtyping and overloading, to which you can take a high-tech approach by using a fancy constraint or inference system, or a low-tech approach by requiring the programmer to add a few more type annotations than they may wish. F# takes the latter approach. IMHO problem (a) will always be the thing that stops Haskell becoming very very big. But then being non-imperative it's also its main selling point... Best wishes, Don -----Original Message----- From: D. Tweed [mailto:tweed@compsci.bristol.ac.uk] Sent: 30 May 2002 15:25 To: Don Syme Cc: Paul Hudak; haskell Subject: RE: [Fwd: F#] On Thu, 30 May 2002, Don Syme wrote:

going to provide. Given the general complexity of GHC, the longish compile times and the reliance of the GHC library implementation on C and C libraries in so many places I decided to implement a simpler language from scratch. I like the idea that a .NET compiler should be under 10K lines of code if at all possible, as is the case for 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? (I'm just interested in that there's little chance of Haskell becoming more widespread if it's daunting enough to dissuade implementors.) ___cheers,_dave_________________________________________________________ www.cs.bris.ac.uk/~tweed/ | `It's no good going home to practise email:tweed@cs.bris.ac.uk | a Special Outdoor Song which Has To Be work tel:(0117) 954-5250 | Sung In The Snow' -- Winnie the Pooh