元循环评价器概念

Question

我试着理解元循环评估器的概念。根据维基百科

在计算中，元循环评估器或元循环解释器是一种解释器，它使用解释器的宿主语言的类似功能来定义解释语言的每个特性。例如，可以使用函数应用程序实现对lambda应用程序的解释。

在Lisp的上下文中，我认为这意味着解释器实现将程序状态存储在语法本身所熟悉的数据结构中，即列表。

更广泛地说，我认为解释器实现使用语法的范例来解释语法。而且，它与用解释语言实现的解释器无关(Lisp解释器通常用C编写)。只有范式对等才是重要的。

让我们考虑一下Java，一个元循环的Maxine虚拟机。Maxine是用Java编写的。它是运行在JVM中的JVM。同样，解释器使用与解释语言相同的范式。Java对象表示的可执行代码由Java对象表示的可执行代码管理。当然，实际的可执行文件是字节代码，但是超越它的抽象概念才是最重要的。因此，我相信Maxine可能是用任何语言编写的，并且仍然被认为是元循环，只要实现与OOP概念和Java规则相匹配。最明显的是，这种语言就是Java本身。然而，这里有一个有趣的冲突，我在最后一段描述，它真的使我的头部受伤！

这就是我在理论上如何理解元循环评估器的含义。但我不太懂实际的一面。根据维基百科

与现有的语言实现相结合，元循环解释器提供了一个基线系统来扩展一种语言，要么通过增加更多的特性，要么向下编译，而不是解释它们。

这到底是什么意思？例如，这是如何在Maxine虚拟机中实现的？这与像eval这样的函数有何不同？

如果我们更有哲理的话，对于元循环解释来说有两个前提。

• 解释器实现语言不重要，范式等价
• 在执行层面，范例的概念不再存在，一切都只是字节。

元循环的明确边界是什么？这个特性实际上是在哪里实现的呢？我可能想得太多了，但我觉得这是个有趣的话题。

Answer 1

基于Java的分析是关闭的，因为

• Java不是JVM。
• Java是在Lisp之后使用的。Lisps被编译成本机代码或类似于JVM的虚拟机。

因此，假设Lisp元循环解释器正在解释函数调用。当然，函数调用是使用列表语法表示的。解释器遍历列表，计算函数和参数(递归使用自身)，然后执行函数调用。它是如何做到这一点的:通过在函数和参数列表上使用apply。这就是所谓的“元循环”的意思。解释器的程序员不必编写函数应用程序，只是从宿主语言中借用了它。

但是，解释器不一定是由列表组成的；它可以编译Lisp代码。它并不是真正地生成(apply ...)表单并将其传递给eval；它包含对apply的编译调用。

元循环Lisp解释器以多种方式隐式地使用了宿主语言。首先，它没有自己的读取器；主机Lisp的读取器被使用，解释器正在处理现成的语法。它不需要重新实现符号实习。如果需要测试程序中的变量引用是否与定义匹配，则只需使用主机的eq函数来比较符号。

“元循环”的灵感可能来自于这样一种想法，即解释器能够忠实地处理宿主语言的每一种特殊形式，从而能够完全实现它。在这一点上，它已经“一圈圈”：它可以解释它自己的实施。

元循环解释被用于教育，因为它允许用语言本身来表达语言的评价模型。好吧，不是评估模式；只是一个评估模型，而且通常是非常低效的。例如，它可以提供一个词汇环境模型，即assoc列表。(而运行解释器的已编译的Lisp代码并不对自己的词法变量使用这种方法；它实际上是将变量放入堆栈框架或闭包向量中。)