是否有可能为动态语言创建编译器而不会失去其动态特性？

Question

是否有一些原因使得动态语言​​(如Python或Ruby )不可能被编译，而不可能在不失去任何动态特性的情况下进行解释？

当然，假设编译器的一个要求是，这些语言不会失去他的任何特性，比如元编程、扩展对象、添加代码或在运行时修改类型系统。

总之，可以创建Ruby或Python编译器，而不会失去他作为动态编程语言的任何特性？

Answer 1

是的，为动态语言创建编译器是绝对可能的。在野外有无数用于动态语言的编译器的例子：

• CPython是programming语言的一个实现，它有一个Python编译器。
• PyPy是programming语言的一个实现，它有一个Python编译器。
• Jython是Python编程语言的实现，它有Python编译器。
• IronPython是programming语言的一个实现，它有一个Python编译器。
• Pynie是Python编程语言的实现，它有Python编译器。
• YARV是Ruby编程语言的一个实现，它有Ruby编译器。
• Rubinius是Ruby编程语言的一个实现，它有一个Ruby编译器。
• MacRuby是Ruby语言的一个实现，它有一个Ruby编译器。
• JRuby是Ruby语言的一个实现，它有一个Ruby编译器。
• IronRuby是Ruby语言的一个实现，它有一个Ruby编译器。
• MagLev是Ruby语言的一个实现，它有一个Ruby编译器。
• Quercus是具有PHP编译器的PHP编程语言的实现。
• P8是programming语言的一个实现，它有一个PHP编译器。
• V8是ECMAScript编程语言的一个实现，它有一个ECMAScript编译器。

一般来说，每种语言都可以由编译器实现，每种语言都可以通过解释器来实现。也可以从解释器自动派生编译器，反之亦然。

大多数现代语言实现同时使用解释和编译，有时甚至使用几个编译器。以Rubinius为例:首先将Ruby代码编译成Rubinius字节码。Rubinius字节码随后由Rubinius解释。经过多次解释的代码随后被编译为Rubinius Compiler IR，然后再编译为LLVM IR，然后再编译为“本机代码”(不管是什么)。因此，Rubinius有一个解释器和三个编译器。

V8是一个不同的例子。它实际上没有解释器，但是有两个不同的编译器:一个非常快速、非常节省内存的编译器，它产生未优化的、有点慢的代码。已经多次运行的代码会被丢弃，然后用第二个编译器再次编译，这会产生积极优化的代码，但在编译过程中会花费更多的时间和更多的内存。

但是，最后，如果没有解释器，您就无法运行代码。编译器无法运行代码。编译器将程序从一种语言转换成另一种语言。就这样。你可以翻译所有你想要的，最后，一些东西必须运行代码，而这是一个解释器。它可以在软件或硅中实现，但它仍然是一个解释器。

Answer 2

我假设“编译”指的是“编译到本机代码”，让其他人来挑战这个非常狭窄的定义。答案是响亮的是。事实上，人们现在正在这样做：

• 努特卡
• Cython (实际上不是Python，但非常接近，可以用来支持完整的Python)。
• 各种“冻结”工具，尽管从技术上讲，这些工具只将字节码和字节码解释器打包成一个二进制文件。

然而，这样的编译器不能执行许多优化(实际上是零)优化，因此生成的代码基本上等同于一个简单的解释器所能做的事情，并且只会节省解释开销(而且您会丢失一些解释器的好特性，包括紧凑的代码和更快的周转速度)。换句话说：动态的，正确的，快速的-选择两个 (完全披露:公认的答案是我的)。