I think almost all of the issues described in your second link[1] still apply. Using something like LLJVM takes care of generating native CLR IL or JVM bytecode, but that's just the first part of the equation. We'd still need to take care of interoperation and reimplementing either primops or parts of the standard library directly.

On top of this, there's a good chance that it won't be very fast, even with GHC's optimizations. The JVM is not designed with functional programming in mind, so things like the garbage collector are tuned very differently from GHC's. I know that a lot of Scala programmers have run into problems with more advanced functional idioms performing slowly, so it's already tricky before considering how laziness will make Haskell's performance profile even more foreign to the JVM.

I'm not saying that it's not worth doing, just that there are a lot of challenges to consider. Unfortunately, getting something usable will take more than just using LLJVM.

It might make sense to have a Haskell-like language for the JVM that keeps Haskell's core essence (types, non-strictness, nicish semantics) but doesn't necessarily maintain complete backwards compatibility. I actually know of two such projects off-hand: Frege[2] and Ermine[3].

To my understanding, Frege tries to be pretty close to Haskell[4] while still being practical on the JVM. It's very similar to Haskell 2010, but with slight cosmetic differences, a few new features (records as namespaces) and a standard library (including primitive types like String) based on Java.

Ermine is another JVM language with the "Haskell philosophy", developed at S&P Captial IQ to address some issues they had with functional programming in Scala. It introduces some interesting new type features (a neat extension to row polymorphism) and is generally more of its own language than a Haskell variant *per se*.

Both of these are worth looking into if you're looking for a sane Haskell-like experience on the JVM. I think this sort of compromise—mostly like Haskell, but not striving for full compatibility—is the best option right now. It just feels like the additional costs involved in supporting all of Haskell, or even a sizable fraction, are too great, especially considering the additional changes to the language needed for interpolation with the rest of the JVM world.


On Wed, Jul 23, 2014 at 7:26 PM, Wojciech Danilo <wojciech.danilo@gmail.com> wrote:
Hello! I was recently discussing with some frients possibilities of running Haskell programs on JVM.
I belive such possibility could be a breakdown for the popularity of Haskell and could be very interesting for new people and new usage-scenarios.

I have seen some topics, like these:
http://stackoverflow.com/questions/7261039/haskell-on-jvm
http://www.haskell.org/haskellwiki/GHC/FAQ#Why_isn.27t_GHC_available_for_.NET_or_on_the_JVM.3F
http://www.haskell.org/pipermail/haskell-cafe/2009-June/063454.html

but are a little old and do NOT mention the LLVM backend. If we've got the LLVM backend in GHC right now, why cannot we just use something like LLJVM to convert the LLVMIR into JVM bytecode? 
I understand that the LLVM bytecode (optained from GHC) has all the optimizations applied (including tail recursion expansion) so it **could** be possible to just run it on JVM?

All the best,
Wojciech Daniło

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe