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.
[1]:
http://www.haskell.org/haskellwiki/GHC/FAQ#Why_isn.27t_GHC_available_for_.NE...
[2]: https://github.com/Frege/frege
[3]: https://github.com/ermine-language/ermine
[4]:
https://github.com/Frege/frege/wiki/Differences-between-Frege-and-Haskell
On Wed, Jul 23, 2014 at 7:26 PM, Wojciech Danilo
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_.NE... 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