Was ist die genaue Definition eines Metacircular Interpreters?

Ist es legal, einen in C geschriebenen C-Compiler oder einen in PHP geschriebenen PHP-Interpreter metacircular zu nennen? Gilt diese Definition nur für Sprachen eines bestimmten Typs wie Lisp? Kurz gesagt, was sind die Bedingungen, die ein Dolmetscher erfüllen sollte, um Metacircular genannt zu werden?

Ein metazirkularer Interpreter ist ein Interpreter, der in einer (möglicherweise einfacheren) Implementierung derselben Sprache geschrieben ist. Dies geschieht normalerweise, um mit dem Hinzufügen neuer Funktionen zu einer Sprache zu experimentieren oder einen anderen Dialekt zu erstellen.

Der Grund, warum dieser Prozess mit Lisp in Verbindung gebracht wird, ist das sehr klare Papier „Die Kunst des Dolmetschers“, das mehrere metazirkuläre Interpreter basierend auf Scheme zeigt. (Das Papier ist der Kern für das Buch SICP, und sein viertes Kapitel arbeitet durch andere, die z. B. ein faul evaluiertes Schema erstellen.)

Das ist auch erheblich einfacher in einer “homoikonischen” Sprache (einer Sprache, deren Code zur Laufzeit als Daten manipuliert werden kann) wie Lisp, Prolog und Forth.

Zu Ihrer direkten Frage: Der C-Compiler wäre überhaupt kein Interpreter. Ein Compiler, der in seiner eigenen Sprache geschrieben ist, ist „self-hosting“, was eine ähnliche Eigenschaft ist, aber mehr mit Bootstrapping zu tun hat. Ein PHP-Interpreter in PHP würde wahrscheinlich nicht zählen, da Sie wahrscheinlich einen nicht trivialen Teil der Sprache in dem Prozess neu implementieren würden. Der Hauptvorteil eines herkömmlichen metazirkularen Dolmetschers besteht darin Dies ist nicht erforderlich – Sie können den vorhandenen Parser, die Garbage Collection (falls vorhanden) usw. einbinden und einfach einen Top-Level-Evaluator mit unterschiedlicher Semantik schreiben. In Scheme oder Prolog ist es oft weniger als eine Seite Code.

Hier ist eine Definition von der Wikipedia-Seite für metazirkular:

Ein Meta-Circular-Evaluator ist ein Spezialfall eines Selbst-Interpreters, bei dem die vorhandenen Möglichkeiten des übergeordneten Interpreters direkt auf den zu interpretierenden Quellcode angewendet werden, ohne dass eine zusätzliche Implementierung erforderlich ist.

Die Antwort ist also in beiden Fällen nein:

• Der AC-Compiler ist kein Interpreter (Evaluator). Es übersetzt ein Programm von einem Formular in ein anderes, ohne es auszuführen.
• Ein (hypothetischer) PHP-Interpreter, der in PHP geschrieben ist, wäre ein Selbstinterpreter, aber nicht unbedingt metazirkular.

Ergänzend zu den obigen Antworten: http://www.c2.com/cgi/wiki?MetaCircularEvaluator

In Lisp geschriebenes Lisp implementiert “eval”, indem es “eval” aufruft. Aber es gibt kein „eval“ in vielen anderen Sprachen (und wenn es eines gibt, hat es eine andere Semantik), also müsste stattdessen ein komplett neues Sprachsystem geschrieben werden, eines, das einen detaillierten Algorithmus für „eval“ liefert – was war im metazirkularen Fall nicht erforderlich. Und das ist die Magie von MetaCircularEvaluators: Sie spiegeln eine zugrunde liegende Magie der Sprachen wider, in denen sie möglich sind.

So wie ich es verstehe, Ein metazirkularer Dolmetscher ist ein Dolmetscher, der sich selbst interpretieren kann.

Ein Compiler übersetzt nur Code und führt ihn nicht aus.

Irgendein Turing-vollständige Sprache ist mathematisch in der Lage, jede logische Berechnung zu emulieren, daher hier ein Beispiel mit Python. Anstatt CPython zu verwenden, um diesen Code in CPU-Anweisungen zu übersetzen und auszuführen, könnten Sie auch verwenden PyPy. Letzteres ist Bootstraperfüllt also ein willkürliches Kriterium, das einige Leute verwenden, um a zu definieren metazirkulärer Dolmetscher.

"""
Metacircular Python interpreter with macro feature.
By Cees Timmerman, 14aug13.
"""

import re

def meta_python_exec(code):
    # Optional meta feature.
    re_macros = re.compile("^#define (\S+) ([^\r\n]+)", re.MULTILINE)
    macros = re_macros.findall(code)
    code = re_macros.sub("", code)
    for m in macros:
        code = code.replace(m[0], m[1])

    # Run the code.
    exec(code)

if __name__ == "__main__":
    #code = open("metacircular_overflow.py", "r").read()  # Causes a stack overflow in Python 3.2.3, but simply raises "RuntimeError: maximum recursion depth exceeded while calling a Python object" in Python 2.7.3.
    code = "#define 1 2\r\nprint(1 + 1)"
    meta_python_exec(code)

Der in C geschriebene AC-Compiler ist kein MetaCircularEvaluator, da der Compiler eine äußerst detaillierte und präzise Semantik für jedes einzelne Konstrukt spezifizieren muss. Da hilft auch nicht, dass der Compiler in der Zielsprache geschrieben ist alle; Die gleichen Algorithmen könnten in Pascal oder Java oder Ada oder Cobol übersetzt werden, und es wäre immer noch ein perfekt guter C-Compiler.

Im Gegensatz dazu kann ein MetaCircularInterpreter für Lisp nicht in eine Nicht-Lisp-Sprache übersetzt werden. Das stimmt,
kann nicht sein – zumindest nicht in einer einfachen Eins-zu-Eins-Manier. In Lisp geschriebenes Lisp implementiert “eval”, indem es “eval” aufruft. Aber es gibt kein „eval“ in vielen anderen Sprachen (und wenn es eines gibt, hat es eine andere Semantik), also müsste stattdessen ein komplett neues Sprachsystem geschrieben werden, eines, das einen detaillierten Algorithmus für „eval“ liefert – was war im metazirkularen Fall nicht erforderlich.

Und das ist die Magie von MetaCircularEvaluators: Sie spiegeln eine zugrunde liegende Magie der Sprachen wider, in denen sie möglich sind.