What prevents an efficient Haskell virtual machine (like JVM)?
https://stackoverflow.com/questions/9352744
-
27-10-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianQuestion
I have been wondering, what prevents the development of an efficient virtual machine like JVM or PyPy for Haskell (except maybe development effort)? Is it the language structure? I think languages, that are harder to interpret efficiently (like Python, being very dynamic), already have decent VMs.
Also, if nothing is obstructing such an implementation, would STG be a good target "bytecode", since all optimizations are done on Core?
Are there any articles or blog posts that discuss this topic?
EDITs:
- I am aware of HaLVM, but I don't think it is what I mean.
- I am also aware of
runhaskell, but it is not efficient at all.
Solution
What prevents an efficient Haskell virtual machine?
Nothing - there already has been one, Daan Leijen's LVM. It was efficient enough to be used for the runtime system of Helium (the Haskell "teaching language" from Utrecht University).
That said I don't know if it is used these days, so the question "What prevents an efficient Haskell virtual machine?" could be answered as manpower, continuous investment, etc. When Haskell already has a good compiler, a good VM is a luxury as Paulo Pinto noted already.
OTHER TIPS
I don't have a way to post a comment, and this is maybe even more of an anti-VM than a native-code compiler is, but the OP might be interested in the Reduceron.
I am not aware of any technical restriction applying here. There is a language called Frege, semanticaly close to Haskell, that targets JVM. So it is just that nobody has considered so far that a Haskell-to-JVM compiler was worth the effort. Indeed, as a JVM-skeptic, I wonder what that would bring. If it is just intermediate language portability, I'd rather work on LLVM or on a pre-built binary farm.
UHC has a Javascript backend which of course runs on a browser's Javascript engine. I mean I don't see anything stopping Haskell from targeting different backends. In fact, I think UHC was designed to make it easy to target different backends.
Nothing. See lambdachine. Here're some short notes.
Nothing stops Haskell from having a VM. Haskell works beautifully on the JVM and can be even faster than GHC after JIT warmup in cases where the generated code hits the sweet spot of the JIT compiler. See Eta, a project that brings full GHC 7.10.3 Haskell onto the JVM with type-safe Java interop. It just requires lots of patience and time to work on.
