blocks|key|1951001|text|这是不切实际的；GHC+Core是不可移植的。例如，在32位机器上，64位算术被编译成Core中的外部函数调用，但在64位机器上，它使用本地机器字算术。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1951002|更重要的是，GHC实际上不能读取Core；它可以以几种格式打印出来，但是没有实际的代码来读取其中任何一种格式。我不确定这样做是否会有任何主要的障碍，但这是多年来记录在案的情况，所以我不希望很快出现支持。|1951003|通常情况下，Core与Haskell非常接近；不清楚您会从以这种形式分发代码中购买什么。将Haskell转换为Core所需的时间通常比链接最终程序所需的时间要短，因此它通常不会节省太多的编译时间。|1951004|此外，对核心的检查比对Haskell源代码的检查要少(尽管我认为-dcore-lint会减轻这一点)，有效地将其放入沙箱将是困难的(有安全的Haskell，但没有安全的核心)。当然，如果字节码的来源是可信的，这些缺点就不适用了。|offset|length|style|CODE|1951005|基本上，GHC+Core在很大程度上是一种编译器的中间语言，而不是为此而设计的可移植字节码格式，如Python字节码和JVM。|1951006|顺便说一句，GHC确实有一个字节码解释器，就像GHCi使用的那样。这里使用的字节码也是不可移植的，所以与GHC在正常操作中生成的机器码相比，我想不出有什么优势。|1951007|entityMap^0|0|0|0|W|B|0|0|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|S|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|T|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|U|8|@$H|V|I|W|J|K]]|9|@]|A|$]]|$1|L|3|M|5|6|7|X|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|Y|8|@]|9|@]|A|$]]|$1|P|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]]|Q|$]]

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 <code>-dcore-lint</code> would 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.

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?

GHC Core as "bytecode"?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

据我所知，GHC ( Glasgow Haskell Compiler)将Haskell编译为" Core "，然后将该Core编译为机器码。将Haskell程序作为GHC核心分发，就好像它是“字节码”一样，这是否实用？这样的分发有什么好处吗？为什么或者为什么不？

GHC核心是“字节码”吗？-腾讯云开发者社区-腾讯云

问GHC核心是“字节码”吗？
EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问GHC核心是“字节码”吗？EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问GHC核心是“字节码”吗？
EN