为什么像 ruby​​ 这样的大多数解释型语言不提供可选的编译器？

Question

所有解释型语言最终都不是机器码吗？我很好奇原因是因为公司认为不值得付出努力，是否存在导致不可能的继承冲突，或者其他原因。有没有办法自己捕获脚本执行的机器码？

编辑 我说得松散，因为我不希望标题太长。我知道没有“口译语言”。我说的是通常被解释的语言（不是 c++，不是 rust 等）。

“所有解释型语言最终都不是机器码吗？” - 这是一个反问。答案是简单的“是”。因为这就是计算机的工作原理。

我很好奇为什么大多数使用解释器创建语言的公司不使用编译器来补充它（编译为本机代码）。而且我很好奇是否可以自己记录执行的机器代码。

此外，Jörg W Mittag 的回答具有误导性（并且傲慢）。在“所有”这些编译器中，我看不到一个可以编译为本机代码的编译器。我认为其中之一甚至不再存在（请访问 Rubinius 网站）。我也与其中一些合作过，但它们有局限性（我不能随意采用与标准 ruby​​ 解释器一起工作的重要脚本并编译它）。

Answer 1

为什么大多数解释型语言（如 ruby​​）不提供可选编译器？

没有“解释语言”这样的东西。解释和编译是解释器或编译器（呃！）而不是语言的特征。语言只是一组抽象的数学规则和限制。它既不解释也不编译。它只是是。

这两个术语属于两个完全不同的抽象层次。如果英语是一种类型化语言，则术语“解释语言”将是类型错误。 “解释性语言”这个词甚至没有错，它毫无意义。

每种语言都可以由编译器实现，每种语言都可以由解释器实现。大多数语言都有解释和编译的实现。许多现代高性能语言实现结合了编译器和解释器。

所有解释型语言最终都不是机器码吗？

在某种意义上，每种语言都是对应于该语言的抽象机器的机器代码，是的。 IE。 Ruby 是“Ruby Abstract Machine”的机器语言，它的执行语义与 Ruby 的执行语义完全匹配，其机器语言语法与 Ruby 的语法完全匹配。

如果有继承冲突导致不可能

所有当前存在的 Ruby 实现（有一个警告）至少有一个编译器。大多数有不止一个。至少一个人根本没有翻译。

• Opal 是纯粹编译的。它从不解释。 Opal 中没有解释器，只有编译器。
• YARV 将 Ruby 编译为 YARV 字节码。然后这个字节码被 YARV VM 解释。已经执行超过一定次数的代码然后被编译为底层架构的本机机器代码（即运行 YARV 的 AMD64 版本时，它被编译为 AMD64 机器代码，运行 ARM 版本时，它被编译到 ARM 机器代码等）。
• Artichoke ……有点复杂，但可以说，它不能解释 Ruby。
• MRuby 将 Ruby 编译为 MRuby 字节码。然后这个字节码被 MRuby VM 解释。
• Rubinius 将 Ruby 编译为 Rubinius 字节码。然后这个字节码被 Rubinius VM 解释。已经执行超过一定次数的代码然后被编译为底层架构的本机机器代码（即运行 YARV 的 AMD64 版本时，它被编译为 AMD64 机器代码，运行 ARM 版本时，它被编译到 ARM 机器代码，等等）。 [注意：有几个不同版本的 Rubinius。原始版本有一个本地代码编译器。这随后被删除，并正在被重写。]
• JRuby 将 Ruby 编译为 JRuby IR。然后这个 IR 被 JRuby IR 解释器解释。已执行超过一定次数的代码然后被编译为 JRuby 编译器 IR。然后这个编译器 IR 被进一步编译为 JVM 字节码。这个 JVM 字节码会发生什么取决于 JVM。在 HotSpot JVM 上，JVM 字节码将由 HotSpot 解释器进行解释，HotSpot 解释器会对代码进行分析，然后将经常执行的代码编译为本机机器码。
• TruffleRuby 将 Ruby 解析为 Truffle AST。然后这个 AST 被 Truffle AST 解释器框架解释。然后，Truffle AST 解释器框架将在解释 AST 节点时对其进行专门化，包括可能使用 Graal 将它们编译为本机机器代码。

最后一个纯解释型且没有编译器的主流 Ruby 实现是最初的 MRI，它在几年前就被废弃了。