functional-programming - 元循环评估器概念

Question

我正在尝试理解元循环求值器的概念。根据Wikipedia

In computing, a meta-circular evaluator or meta-circular interpreter is an interpreter which defines each feature of the interpreted language using a similar facility of the interpreter's host language. For example, interpreting a lambda application may be implemented using function application.

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

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

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

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

In combination with an existing language implementation, meta-circular interpreters provide a baseline system from which to extend a language, either upwards by adding more features or downwards by compiling away features rather than interpreting them

这究竟意味着什么？例如，这是如何通过 Maxine Virtual Machine 实现或可能付诸实践的？这与 eval 等函数有何不同？

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

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

元循环的明确界限是什么？这个特性究竟在哪里实现呢？我可能想得太多了，但我发现这是一个有趣的主题。

Answer 1

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

• Java 不是 JVM。

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

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

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

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

“Meta-circular”的灵感可能是解释器可以忠实地处理宿主语言的每一种特殊形式，因此可以完全实现它。到那时它已经“绕了一圈”:它可以解释自己的实现。

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