[Haskell-cafe] GHC for .NET?
dsyme at microsoft.com
Wed Jan 5 07:00:36 EST 2005
> There is some good groundwork already done...
I'd add that during my first effort to do GHC.NET I modified GHC to
optionally preserve full type information through to the backend,
including type applications. This is necessary if you're going to
produce verifiable code.
> The trouble here is that Haskell's type system is more expressive
> than the CLR's in some ways, notably the use of higher-kinded
> type variables.
The problem with higher-kinded type variables is quite significant, and
were one of the reasons I stopped work on ghc.net. It is an open
question as to whether you can compile type parameters to .NET generics
and higher-kinded parameters by some other means (i.e. to casts etc.) -
I believe it is possible by passing term parameters in place of
higher-kinded type variables, where the term parameters are called
whenever the type function is applied. However when I tried to
implement this scheme it got too complex, especially given how few uses
of higher-kinded polymorphism there are in practice. It would probably
be better to initially simply inline all higher-kinded code at the
From: Simon Peyton-Jones
Sent: 04 January 2005 12:18
To: Don Syme; John Goerzen; haskell-cafe at haskell.org
Cc: GHC users
Subject: RE: [Haskell-cafe] GHC for .NET?
| "The GHC compiler for .NET is currently under development at
| Microsoft Research, Cambridge".
| Hmm. That location sounds familiar :-) Does anyone know if this is
| actually going to happen? Or if there's any code anywhere, however
| experimental, to try?
It'd make a lot of sense to give GHC a .NET back end, and it's a
question that comes up regularly. The reason that we haven't done it
here, at GHC HQ, is because it's a more substantial undertaking than
might at first appear (see below). Furthermore, it'd permanently add a
complete new back-end platform for us to maintain. Given our rather
limited development effort (= Simon and me), we have so far not bitten
the bullet, and we have no immediate plans to do so.
It'd be a good, well-defined project for someone else to tackle, and
there is some good groundwork already done:
* Sigbjorn Finne did a simple interop implementation that allows a
to be compiled to native code (as now) but to call .NET programs
via a variant
of the FFI. I don't think this work is in active use, and I'd
be surprised if it worked
out of the box, but it could probably be revived with modest
* Andre Santos and his colleagues at UFPE in Brazil are working on a
.NET back end,
that generates CLR IL, though I don't know where they are up to.
* GHC.Net would be extra attractive if there was a Visual Studio
integration for GHC.
Substantial progress on this has been made in 2004 by Simon
Angelov, and Andre Santos and colleagues.
There may be others that I don't know of. If anyone wants to join in
this effort, do contact the above folk. And please keep us informed!
Here's a summary of why it's a non-trivial thing to do:
- The first thing is to generate native CLR Intermediate Language (IL).
really hard. Requires thinking about representations for thunks
and it may not be particularly efficient, but it can surely be
done. An open
question is about whether to generate verifiable IL or not. The
is that Haskell's type system is more expressive than the CLR's
in some ways,
notably the use of higher-kinded type variables. So, to
generate verifiable IL
one is bound to need some run-time casts, and it's not clear how
At first blush this is *all* you need do. But it isn't!
- Next, you need to think about how to inter-operate with .NET
libraries. You don't
really want to write "foreign import..." for each and every
import. You'd like
GHC to read the CLR meta-data directly. But there are lots of
tricky issues here;
see the paper that Mark Shields and I wrote about
"Object-oriented style overloading
- Now you need to figure out how to implement GHC's primitive
the I/O monad
arbitrary precision arithmetic
software transactional memory
Not all of these are necessary, of course, but many are used in the
libraries. The CLR
supports many of them (e.g. concurrency) but with a very different
- Last, you have to figure out what to do for the libraries. GHC has a
library, and you either have to implement the primops on which
is based (see previous point), or re-implement it. For example,
implementation of I/O uses mutable state, concurrency, and more
For each module, you need to decide either to re-implement it
primitives, or to implement the stuff the module is based on.
These challenges are mostly broad rather than deep. But to get a
production quality implementation that runs a substantial majority of
Haskell programs "out of the box" requires a decent stab at all of them.
More information about the Haskell-Cafe