GHC targetting Java?

[Simon Peyton-Jones]

| On a similar note, how about the .NET support?  Can it work on a
| platform where the only .NET support is Mono?

This comes up regularly. Here's my message from Jan:
http://www.haskell.org/pipermail/glasgow-haskell-users/2005-January/0075
94.html

Simon

===========================
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
  Haskell program 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 effort

* 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.

* [This para wasn't in the original message]
  Nigel Perry and Oliver Hunt have a Haskell.NET prototype that works
  using GHC to compile to Core, and then compiling Core to NET.  I'm
  not sure what stage it is at.

* 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 Marlow, Krasimir 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!

Simon


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). That's not really hard.  Requires thinking about
  representations for thunks and functions, 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 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.  So, to
  generate verifiable IL one is bound to need some run-time casts, and
  it's not clear how to minimise these.

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 for Haskell".

* Now you need to figure out how to implement GHC's primitive
  operations:
	the I/O monad
	arbitrary precision arithmetic
	concurrency
	exceptions
	finalisers
	stable pointers
	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 cost model.

* Last, you have to figure out what to do for the libraries.  GHC has
  a pretty large library, and you either have to implement the primops
  on which the library is based (see previous point), or re-implement
  it.  For example, GHC's implementation of I/O uses mutable state,
  concurrency, and more besides. For each module, you need to decide
  either to re-implement it using .NET 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.