口译员和动态类型语言

时间:2010-12-08 21:25:49

标签: compiler-construction programming-languages interpreter dynamic-languages

为什么具有动态类型语言的程序通常被解释而不是编译?

6 个答案:

答案 0 :(得分:5)

简而言之:他们像豌豆和胡萝卜一样走在一起。

编译与口译和语言类型从根本上是独立的问题,因为您可以拥有所有可能的排列。另一方面,选择编译而不是为语言设计选择动态类型的“原因”通常是相同的:性能。选择动态类型和解释的“原因”也有些相关。

这不是一个硬性规定。你可以随时混合起来。例如,您可以编译Perl和Lisp并解释C.

答案 1 :(得分:3)

您正在观察非因果关系:

  • 动态类型和解释相互关联,因为两者都易于实现。
  • 静态类型和编译相互关联,因为两者都有利于可预测的良好性能。

编译器通常会改装为动态类型语言,以提高性能(因为性能通常很差)。例如,这是在编写第一个编译器之前解释一些主要动态类型语言的时间长度:Lisp(1958-1962),Mathematica(1988-2004),Lua(1993-2004),Python(1991-2002)和Javascript(1995-2009)。相比之下,OCaml(1996)和F#(2001)等语言首先作为编译器发布。

答案 2 :(得分:2)

正如其他人所指出的,语言既不是编译也不是解释。它们只是需要翻译的规则,大多数都有解释和编译实现。即使这样,当许多“解释器”在jitting到处都是eval function时,很难谈论解释与编译,如果源文件发生变化,一些“编译器”很乐意按需编译。

将实施分类为完全预编译按需编译可能更好。如果我们使用这些类别,那么打破完整预编译的一件事是{{3}}。这可能比动态类型对实现有更多影响。如果您有eval函数,则需要支持按需编译。

答案 3 :(得分:1)

Common Lisp代码主要是编译的。 Common Lisp编程语言已在ANSI标准中描述,支持编译。 ANSI标准描述了编译代码的函数,描述了优化的各个方面,描述了编译过程的各个方面等。

Common Lisp的解释器存在,但不常使用。

Common Lisp实现通常可以自由地混合不同的执行模式。几乎所有人都有编译器。少数人只有编译器。

几乎所有实现中的编译都有增量模式,因此可以交互使用。所有都可以编译文件。有些人使用“块编译”模式来编译文件组。

答案 4 :(得分:0)

根据动态类型语言的定义......

  

当编程语言的大多数类型检查在运行时执行而不是在编译时执行时,它被称为动态类型。在动态类型中,值具有类型但变量不具有类型;也就是说,变量可以引用任何类型的值。

也就是说,很难知道编译程序的是什么,因为它可能会在运行时更改。维基百科的另一个摘录...

  

动态类型允许构造   一些静态类型检查会拒绝   非法。例如,eval   函数,执行任意   数据作为代码,成为可能。   此外,动态打字更好   适应过渡代码和   原型设计,例如允许   占位符数据结构(模拟   对象)透明地使用   一个完整的数据结构的地方   (通常用于...的目的   实验和测试)。

我觉得这个答案仍然不完整,但我希望它能指出你正确的方向。也许这里的其他人可以扩展这个。

答案 5 :(得分:-8)

检查类型一次实际上是什么使“编译器”(〜类型检查器)。

当类型为“动态”时,您无法“编译”(检查类型一次)。