| Understandably, however, there is real resistance in language communities like Haskell's to changing | or even extending a language for the sake of interoperability and API access: instead people work | incredibly hard to encode interoperability via existing mechanisms. In the end, whoever picks up the | burden of doing Haskell.NET will face the same unenviable choice that every other .NET language | design group has faced: | | (a) do you modify and/or extend the language to make "the nicest possible Haskell-like language in | the context of .NET" | | or (b) do you implement Haskell faithfully without language extensions, but where using the .NET | libraries is in practice somewhat arcane and unpleasant, probably sufficiently so that you'll be unable | to attract .NET-savvy programmers to your language. | | Personally I think language designs in space (a) are more interesting, since perfectly good native | implementations of Haskell are already available on most platforms. I also think you learn a lot more | by trying to create something new, and you give yourself the maximum possible long-term chance of | rivalling other .NET languages (which I think should be an important goal for a Haskell.NET). I agree with all of that, including leaning towards (a) -- and it also helps to explain why we have moved so slowly on the GHC.net front. GHC is a big system already, and specifically tries to be multi-platform. Making substantial, but platform-specific, language changes is arguably the Right Thing (as Don says), but not so attractive for GHC. Simon