我试图理解元循环评估者的概念。根据{{3}}
在计算中，元循环评估器或元循环解释器是一种解释器，它使用解释器宿主语言的类似功能来定义解释语言的每个特征。例如，解释lambda应用程序可以使用函数应用程序来实现。
在Lisp的上下文中，我认为这意味着解释器实现将程序状态存储在语法本身所表达的数据结构中，即列表。
更一般地说，我会说解释器实现使用语法的范例来解释语法。此外，它与解释语言中实现的解释器无关（Lisp解释器通常用C语言编写）。只有范式等同才重要。
让我们考虑Java Wikipedia，即元循环JVM。 Maxine JVM是用Java编写的。它是在JVM中运行的JVM。同样，解释器使用与解释语言相同的范例。由Java对象表示的可执行代码由Java对象表示的可执行代码管理。当然，实际的可执行文件是字节代码，但超出它的抽象概念才是最重要的。因此，我相信Maxine可能是用任何语言编写的，并且仍被视为元循环，只要该实现与OOP概念和Java规则匹配即可。最明显的这种语言是Java本身。然而，这是我在最后一段描述的一个有趣的冲突，它真的让我的头受伤了！
这就是我理解元循环评估者在理论上的含义。但我真的没有实际的方面。根据维基百科
结合现有的语言实现，元循环解释器提供了一个基线系统，可以通过添加更多功能向上扩展语言，或通过编译功能而不是解释它们来向下扩展语言
这究竟意味着什么？例如，如何使用Maxine虚拟机实现或可能将其付诸实践？这与eval？
如果我们更具哲学性，有两个前提是元循环翻译
元循环的最终边界是什么？这个特征实际上在哪里实现？我可能会过度思考这个问题，但我发现这是一个有趣的主题。
答案 0 :(得分：0)
您的基于Java的分析已关闭，因为
Java不是JVM。
Java在Lisp之后蠢蠢欲动。 Lisps被编译为本机代码或类似于JVM的虚拟机。
因此，假设一个Lisp元循环解释器正在解释一个函数调用。当然，使用列表语法表示该函数调用。解释器遍历列表，评估函数和参数（递归使用自身），然后执行函数调用。它是如何做到的：在函数和参数列表上使用apply。那应该是什么＆＃34; meta-circular＆＃34;手段。口译员的程序员不必写函数应用程序，而只是从宿主语言中借用它。
但是，口译员不一定是由名单组成的;它可能是编译Lisp代码。它不会真正生成(apply ...)形式并将其交给eval;它包含对apply的编译调用。
元循环Lisp解释器隐式地以多种方式使用宿主语言。首先，它没有自己的读者;使用主机Lisp的阅读器，解释器正在研究现成的语法。它不必重新实现符号实习。如果需要测试程序中的变量引用是否与定义匹配，则只需使用主机的eq函数来比较符号。
＆＃34;元圆形＆＃34;可能的灵感来自于解释器可以忠实地处理宿主语言的每种特殊形式，因此可以完全实现它。那时它已经完全循环了＃34;它可以解释它自己的实现。
元循环解释用于教育，因为它允许语言的评估模型用语言本身表达。好吧，不是 评估模式;只是 评估模型，通常效率非常低。例如，它可以提供词汇环境模型，该列表是assoc列表。 （而运行解释器的已编译的Lisp代码并没有将这样的东西用于它自己的词法变量;它实际上将变量放入堆栈帧或闭包向量中。）