是什么阻碍了高效的 Haskell 虚拟机（如 JVM）？答案

【问题标题】：What prevents an efficient Haskell virtual machine (like JVM)?是什么阻碍了高效的 Haskell 虚拟机（如 JVM）？
【发布时间】：2012-03-10 07:10:02
【问题描述】：

我一直在想，是什么阻碍了像 JVM 或 PyPy for Haskell 这样的高效虚拟机的开发（除了开发工作之外）？是语言结构吗？我认为更难有效解释的语言（如 Python，非常动态）已经有了不错的 VM。

另外，如果没有什么阻碍这样的实现，STG 是否会成为一个很好的目标“字节码”，因为所有优化都是在 Core 上完成的？

有没有讨论这个话题的文章或博客文章？

编辑：

我知道HaLVM，但我认为这不是我的意思。
我也知道runhaskell，但是一点效率都没有。

【问题讨论】：

他们不是。JVM 是一个通用的虚拟机，理论上你可以编译任何语言给它。也许不是最好的性能，但它会起作用。
1) GHC 做到了 2) 你不需要 JVM 尾调用优化，你可以发出已经优化的代码。
当 Haskell 已经编译成相当高效的本机代码时，为什么还要为它创建一个 VM？
@yi_H，在没有适当尾调用的情况下将函数式语言编译为语言或 VM 的主要两种方法是（1）作为一个大函数，或（2）使用蹦床。两者都不是 JVM 上的真正选择。一般来说，关闭、重击和分配的成本是其他阻碍因素。尽管大肆宣传，但 JVM 远非通用 VM。
@yi_H：记住尾递归也适用于相互递归的函数。在这种情况下，很难将优化转变为迭代循环。

标签： haskell jvm vm-implementation

【解决方案1】：

我没有办法发表评论，这可能比原生代码编译器更像是一种反虚拟机，但 OP 可能对 Reduceron. 感兴趣

【讨论】：

【解决方案2】：

是什么阻碍了高效的 Haskell 虚拟机？

什么都没有 - 已经有一个，Daan Leijen 的 LVM。它的效率足以用于 Helium（来自乌得勒支大学的 Haskell“教学语言”）的运行时系统。

也就是说我不知道这几天有没有用，所以“是什么阻碍了高效的 Haskell 虚拟机？” 可以回答为人力，持续投资 em> 等等。当 Haskell 已经有了一个好的编译器时，一个好的 VM 是一种奢侈，正如 Paulo Pinto 已经指出的那样。

【讨论】：

【解决方案3】：

UHC 有一个 Javascript 后端，它当然运行在浏览器的 Javascript 引擎上。我的意思是我没有看到任何阻止 Haskell 针对不同后端的东西。事实上，我认为 UHC 旨在让定位不同的后端变得容易。

【讨论】：

【解决方案4】：

我不知道这里有任何技术限制。有一种名为Frege 的语言在语义上接近于 Haskell，它以 JVM 为目标。因此，到目前为止，没有人认为 Haskell-to-JVM 编译器值得付出努力。事实上，作为一个 JVM 怀疑论者，我想知道这会带来什么。如果只是中间语言可移植性，我宁愿在 LLVM 或预构建的二进制农场上工作。

【讨论】：

已经尝试将 Haskell 用于 JVM（例如搜索 LambdaVM），但它们似乎都卡住了。
iinm，Frege 实际上编译为 Java，Java 编译为 JVM 字节码。 Frege 和 Haskell 之间的一些根本区别在于原始类型：Frege 使用 Java 的 String、int 等，而 Haskell 对它们的指定不同。
@Dan - String 在 Haskell 中并不完全是原始类型，是吗？关于 int，Haskell 标准并没有规定如何实现 int，我敢打赌 Haskell 使用 C int。

【解决方案5】：

什么都没有。见lambdachine。这里有一些short notes。

【讨论】：

【解决方案6】：

没有什么能阻止 Haskell 拥有虚拟机。 Haskell 在 JVM 上运行良好，并且在生成的代码达到 JIT 编译器的最佳位置的情况下，在 JIT 预热后甚至可以比 GHC 更快。请参阅Eta，该项目通过类型安全的 Java 互操作将完整的 GHC 7.10.3 Haskell 引入 JVM。它只需要大量的耐心和时间来完成。

【讨论】：