3

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

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

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

更一般地说，我会说解释器实现使用语法的范式来解释语法。此外，它与以解释语言实现的解释器无关（Lisp 解释器通常用 C 编写）。只有范式对等很重要。

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

这就是我在理论上理解元循环评估器的含义的方式。但我并没有真正了解实际方面。根据维基百科

与现有的语言实现相结合，元循环解释器提供了一个基线系统，可以从中扩展语言，向上通过添加更多特性或向下编译特性而不是解释它们

这实际上意味着什么？例如，这是如何使用 Maxine 虚拟机实现或可能付诸实践的？这与诸如 的函数有何不同eval？

如果我们更哲学一点，元循环解释器有两个前提

  • 解释器实现语言无关紧要，范式等价才是
  • 在执行层面，范式的概念不复存在，一切都只是字节

元循环的明确边界是什么？这个特性究竟体现在哪里？我可能想多了，但我觉得这是一个有趣的话题。

4

1 回答 1

1

您的基于 Java 的分析已关闭，因为

  • Java 不是 JVM。

  • Java 模仿 Lisp。Lisp 被编译为本地代码或类似于 JVM 的虚拟机。

所以，假设一个 Lisp 元循环解释器正在解释一个函数调用。当然，该函数调用是使用列表语法表示的。解释器遍历列表，评估函数和参数（递归使用自身），然后执行函数调用。它是如何做到的：通过使用apply函数和参数列表。据说这就是“元循环”的意思。解释器的程序员不必编写函数应用程序，而只是从宿主语言中借用它。

但是，解释器不一定由列表组成；它可能是编译的 Lisp 代码。它并不是从字面上生成一个(apply ...)表格并将其交给 eval ；它包含对apply.

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

“元循环”可能是受到解释器可以忠实地处理宿主语言的每一种特殊形式的想法的启发，因此可以完全实现它。到那时，它已经“绕了一圈”：它可以解释自己的实现。

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

于 2018-04-22T15:05:16.370 回答