* Niklas Larsson:
http://www.haskell.org/haskellwiki/GHC/FAQ#Why_isn.27t_GHC_available_for_.NE... "It would make a lot of sense to give GHC a .NET or JVM 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, we have so far not bitten the bullet, and we have no immediate plans to do so."
The big problem seems to be to create a sensible interop to an object-orientated framework.
I think this is completely backwards. The hard part is porting the STG machine to the JVM in such a way that performance (speed and memory consumption) is acceptable. A toy port is probably not that hard if you know you way around in GHC, but its performance will be horrible. Useful Java interop is easy once you run on the JVM. There are already bindings for large OO code bases with their own object systems, so it's definitely possible to access OO code. Seemless interop is very difficult, but I don't think it's necessary.