是不是有一些原因使得 Python 或 Ruby 等动态语言无法编译而不是解释而不失去他的任何动态特性?
当然,假设编译器的一个要求是这些语言不会失去他的任何特征,如元编程、扩展对象、添加代码或在运行时修改类型系统。
总而言之,是否可以创建一个 Ruby 或 Python 编译器而不会失去其作为动态编程语言的任何特性?
是不是有一些原因使得 Python 或 Ruby 等动态语言无法编译而不是解释而不失去他的任何动态特性?
当然,假设编译器的一个要求是这些语言不会失去他的任何特征,如元编程、扩展对象、添加代码或在运行时修改类型系统。
总而言之,是否可以创建一个 Ruby 或 Python 编译器而不会失去其作为动态编程语言的任何特性?
是的,绝对可以为动态语言创建编译器。有无数的动态语言编译器示例:
一般来说,每种语言都可以由编译器实现,每种语言都可以由解释器实现。也可以从解释器自动派生编译器,反之亦然。
大多数现代语言实现都使用解释和编译,有时甚至使用多个编译器。以 Rubinius 为例:首先将 Ruby 代码编译为 Rubinius 字节码。Rubinius 字节码随后由 Rubinius VM 解释。经过多次解释的代码然后被编译为 Rubinius Compiler IR,然后编译为 LLVM IR,然后编译为“本机代码”(无论是什么)。所以,Rubinius 有一个解释器和三个编译器。
V8 是一个不同的例子。它实际上没有解释器,但有两种不同的编译器:一种非常快速、非常节省内存的编译器,它生成未优化的、有点慢的代码。然后丢弃已经运行多次的代码,并使用第二个编译器再次编译,这会产生积极优化的代码,但在编译期间需要更多时间并使用更多内存。
但是,最终,您无法在没有解释器的情况下运行代码。编译器无法运行代码。编译器将程序从一种语言翻译成另一种语言。就是这样。你可以翻译所有你想要的,最后,必须有一些东西来运行代码,那个东西就是解释器。它可能在软件或芯片中实现,但它仍然是一个解释器。
我将假设“编译”您的意思是“编译为本机代码”,并将其留给其他人来挑战这个非常狭窄的定义。答案是肯定的。事实上,人们现在正在这样做:
但是,这样的编译器不能执行很多(我会说实际上是零)优化,因此生成的代码基本上等同于头脑简单的解释器所做的,并且您只会节省解释开销(并且您会失去一些不错的属性解释器,包括紧凑的代码和更快的周转)。换句话说:动态、正确、快速 - 选择两个(完全披露:接受的答案是我的)。