运行时通常使用函数语言代码的命令式解释

时间:2012-06-20 03:24:54

标签: haskell functional-programming ocaml interpreter imperative-programming

关于函数式语言的解释,我有一个普遍的问题:

在运行时使用功能语言与命令式语言(或者使用解释器)实际上是否有任何优势?

我看到的所有问题(例如this)都没有真正得到这个问题,搜索中充满了关于不同语言定义的争论。

编辑:剥离到我最终需要回答的唯一问题。

2 个答案:

答案 0 :(得分:29)

简短的回答是:一切都被编译成一些低级语言(汇编或虚拟机语言)。功能性和命令式语言处于平等地位:他们必须编译其抽象机制以适应机器上可用的内容。
语言有所不同的是它们与底层低级代码的匹配程度(通过提供低级功能以在需要时手动优化代码)以及通过提供强大推理保证的干净语义来实现或更轻松实现的优化。 / p>

例如,在编译为本机代码时,递归不会(通常)编译成循环,而是跳转到标签,就像循环一样:大多数汇编语言既没有循环也没有递归。当然,如果编译到具有循环但没有跳转的虚拟机,则需要生成循环;这是一个问题,例如在Java虚拟机上,因为一般的尾调用比单独的循环更具表现力,你需要解决这个限制,放弃一些效率。

功能程序的“优点”可能是因为语义表现更好,您可以更容易地推理程序,例如以更简单的方式表达优化。现在很多编译器使用Single Static Assignment (SSA)中间形式,它基本上是一种低级功能语言¹ - 虽然它是由编译器社区的人独立发现的。例如,当您消除了变量突变时,大多数优化都更容易实现,并且变量在其所有范围内保持相同的值。有一些技术可以在more efficient ways中对这些功能中间形式进行寄存器分配。

¹:见Andrew Appel 1998年的短篇文章:SSA is Functional Programming;如果您对SSA表单的详细信息感兴趣,请参阅some reading notes关于SSA与其他功能中间表格之间的关系,例如CPS

您还可以从纯度获得优化优势(没有副作用,或者至少可以很好地控制哪些计算将是无副作用的)和静态类型。从纯度上你可以得到强大的优化,例如deforestationfusion(消除中间数据结构),从输入中你可以得到你的价值形状的强有力保证(这就是为什么一些动态语言试图允许用于优化目的的一些限制形式的类型注释),可以生成更好的代码。

关于对低级功能的访问:Fortran,C和C ++可能是最好的,也是最广泛可用的,“可以是非常低级别的”语言。有些语言试图提供其中的一些功能:例如ATS(最初是一种函数式编程语言,虽然它很难看,但它很难看到)提供了对堆栈分配版本堆分配的良好控制,{ {3}}和Haskell提供了未装箱的复合类型作为此类低级推理的特殊情况,同样the CLR (C#,etc.)正在尝试为您提供有关内存消耗的低级决策的方法。 /> 然而,当你分离出对你的表演至关重要的一小部分代码并且你想要优化地狱(放弃一些灵活性/简单性/可维护性)时,这肯定是有用的,这不会改变你的生活在日常情况下,除非您是嵌入式/内核程序员。您可能会从一种高效的语言中获得更多的性能提升,这种语言允许您使用正确的抽象级别,并花更多的时间为您的问题选择正确的设计和算法。当然,人们可能想要两者兼而有之,但这很有可能。但

答案 1 :(得分:0)

  

在运行时使用功能语言与命令式语言(或者转向解释器)实际上是否有任何优势?

是。如果您使用函数式语言,那么优势在于解释器编写器可能更快。如果你使用命令式的,可以使用更少的内存和CPU。

所以,无论你怎么做,都有优势。

但是,给定两个解释器,一个用命令语言编写,另一个用功能语言编写,并且进一步说它们都是正确的,你无法从程序的结果中看出使用了哪个解释器。 / p>