RE: [Haskell-cafe] GHC for .NET?

| 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