GHC Core 作为“字节码”？
据我了解，GHC（Glorious Glasgow Haskell Compiler）将Haskell编译为“Core”，然后将该Core编译为机器代码。将 Haskell 程序作为 GHC Core 分发，就像“字节码”一样，是否可行？这样的分配有什么好处吗？为什么或为什么不呢？
As I understand it, GHC (the Glorious Glasgow Haskell Compiler) compiles Haskell to "Core", and then compiles that Core into machine code. Would it be at all practical to distribute Haskell programs as GHC Core, as if it were "bytecode"? Would there be any benefit to such a distribution? Why or why not?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这不切实际； GHC Core 不可移植。例如，在 32 位机器上，64 位算术被编译为 Core 中的外部函数调用，但在 64 位机器上，它使用本机机器字算术。
更重要的是，GHC 实际上无法读取 Core；它可以以几种格式打印出来，但没有实际的代码来读取这些格式中的任何一种。我不确定这样做是否会遇到任何重大障碍，但多年来这一直是记录在案的情况，所以我预计不会很快出现支持。
一般来说，Core 也非常接近 Haskell；目前尚不清楚您会通过以这种形式分发代码来购买什么。将 Haskell 转换为 Core 所需的时间通常少于链接最终程序等操作所需的时间，因此通常根本不会节省太多编译时间。
此外，对 Core 的检查比 Haskell 源代码少（尽管我认为
-dcore-lint会减轻这种情况），并且有效地沙箱化它会很困难（有 Safe Haskell，但没有 Safe Core）。当然，如果字节码的来源是可信的，这些缺点就不适用。基本上，GHC Core 在很大程度上是一种编译器的中间语言，而不是为此目的而设计的可移植字节码格式，例如 Python 字节码和 JVM。
附带说明一下，GHC 确实有一个字节码解释器，正如 GHCi 使用的那样。那里使用的字节码也是不可移植的，因此与 GHC 在正常操作中生成的机器代码相比，我认为没有任何优势。
This wouldn't be practical; GHC Core is not portable. For example, on a 32-bit machine, 64-bit arithmetic is compiled down to foreign function calls in the Core, but on a 64-bit machine, it uses native machine-word arithmetic.
More importantly, GHC can't actually read Core; it can print it out in a few formats, but there is no actual code to read any of those formats back in. I'm not sure if there would be any major obstacle to doing so, but it's been the documented situation for many years, so I wouldn't expect support to appear any time soon.
Core is also pretty close to Haskell in general; it's not clear what you'd buy from distributing code in that form. The time it takes to turn Haskell into Core is usually going to be less than the time it takes to do things like link the final program, so it usually wouldn't save much on compilation time at all.
Also, less checking is done to Core than Haskell source code (although I think
-dcore-lintwould mitigate this), and sandboxing it effectively would be difficult (there's Safe Haskell, but no Safe Core). Of course, these disadvantages don't apply if the source of the bytecode is trusted.Basically, GHC Core is very much a compiler's intermediate language, as opposed to portable bytecode formats designed for the purpose, like Python bytecode and the JVM.
As a side note, GHC does have a bytecode interpreter, as used by GHCi. The bytecode used there is also non-portable, so there are no advantages I can think of compared to the machine code GHC produces in normal operation.