是什么阻碍了 Haskell 虚拟机（如 JVM）的高效运行？
我一直在想，是什么阻碍了像 JVM 或 PyPy for Haskell 这样的高效虚拟机的开发（也许开发工作除外）？是语言结构吗？我认为那些难以有效解释的语言（例如 Python，非常动态）已经拥有不错的虚拟机。
另外，如果没有什么阻碍这样的实现，那么 STG 是否是一个很好的目标“字节码”，因为所有优化都是在 Core 上完成的？
有没有讨论这个主题的文章或博客文章？
编辑：
- 我知道 HaLVM，但我不认为这就是我的意思。
- 我也知道
runhaskell，但它根本没有效率。
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
是什么阻碍了 Haskell 虚拟机的高效运行？
什么都没有——已经有一个了，Daan Leijen 的 LVM。它足够高效，可以用于 Helium（乌得勒支大学的 Haskell“教学语言”）的运行时系统。
也就是说，我不知道现在是否使用它，所以问题“是什么阻碍了高效的 Haskell 虚拟机？”可以回答为“人力、持续投资”，当 Haskell 已经有了一个好的编译器时，一个好的 VM 就成为了一种奢侈，正如 Paulo Pinto 已经指出的那样。
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.
我不知道这里有任何技术限制。有一种名为 Frege 的语言，在语义上接近 Haskell，它的目标是 JVM。所以到目前为止，还没有人考虑过 Haskell 到 JVM 的编译器值得付出努力。事实上，作为一个 JVM 怀疑论者，我想知道这会带来什么。如果只是中间语言的可移植性，我宁愿在 LLVM 或预构建的二进制农场上工作。
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.
我没有办法发表评论，这可能比本机代码编译器更像是反虚拟机，但 OP 可能对 Reduceron。
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.
UHC 有一个 Javascript 后端，当然它运行在浏览器的 Javascript 引擎上。我的意思是，我没有看到任何东西阻止 Haskell 针对不同的后端。事实上，我认为 UHC 的设计初衷是为了让针对不同的后端变得容易。
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.
没有什么。请参阅 lambdachine。这里有一些简短说明。
Nothing. See lambdachine. Here're some short notes.
没有什么可以阻止 Haskell 拥有虚拟机。 Haskell 在 JVM 上运行得非常好，并且在生成的代码达到 JIT 编译器最佳状态的情况下，在 JIT 预热之后甚至可以比 GHC 更快。请参阅 Eta，该项目将完整的 GHC 7.10.3 Haskell 引入 JVM，并提供类型安全的 Java 互操作。它只需要大量的耐心和时间来完成。
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.