没有什么能阻止Haskell拥有VM。Haskell在JVM上工作得很好，在生成的代码达到JIT编译器的最佳点的情况下，在JIT预热后甚至可以比GHC更快。请参阅Eta，该项目使用类型安全的Java互操作将完整的GHC 7.10.3 Haskell引入JVM。这只需要大量的耐心和时间来完成。
我一直在想，是什么阻碍了像JVM或PyPy for Haskell这样高效的虚拟机的开发（除了开发工作）？是语言结构吗？我认为更难有效解释的语言（比如Python，非常动态）已经有了不错的VM。
此外，如果没有任何东西阻碍这样的实现，那么STG是否是一个很好的目标"字节码"，因为所有的优化都是在Core上完成的？
有任何文章或博客文章讨论这个话题吗？
编辑：
- 我知道HaLVM，但我不认为这是我的意思
- 我也知道
runhaskell，但它根本没有效率
是什么阻碍了高效的Haskell虚拟机？
什么都没有——已经有一个了，Daan Leijen的LVM。它的效率足以用于氦的运行时系统（乌得勒支大学的Haskell"教学语言"）。
也就是说，我不知道现在是否在使用它，所以问题"是什么阻碍了一个高效的Haskell虚拟机？"可以用人力、持续投资等来回答。当Haskell已经有了一个好的编译器时，正如Paulo Pinto已经指出的那样，一台好的VM是一种奢侈。
我不知道这里有任何技术限制。有一种叫做Frege的语言，在语义上接近Haskell，它以JVM为目标。因此，到目前为止，还没有人考虑过Haskell到JVM编译器值得这么做。事实上，作为一个JVM怀疑论者，我想知道这会带来什么。如果只是中间语言可移植性，我宁愿在LLVM或预构建的二进制农场上工作。
我没有办法发布评论，这可能比本机代码编译器更像是一个反VM，但OP可能对Reduceron感兴趣。
UHC有一个Javascript后端，当然它在浏览器的Javascript引擎上运行。我的意思是，我看不出有什么能阻止哈斯克尔瞄准不同的后端。事实上，我认为UHC的设计是为了让它更容易针对不同的后端。
什么都没有。参见lambdachine。这是一些简短的笔记。