Interpretierte Sprachen – Nutzung der kompilierten Sprache hinter dem Dolmetscher

Question

Wenn es da draußen Sprachdesigner gibt (oder Leute, die sich einfach auskennen), bin ich neugierig auf die Methodik, die hinter der Erstellung von Standardbibliotheken für interpretierte Sprachen steckt.Was scheint konkret der beste Ansatz zu sein?Standardfunktionen/-methoden in der interpretierten Sprache definieren oder die Verarbeitung dieser Aufrufe in der kompilierten Sprache durchführen, in der der Interpreter geschrieben ist?

Was mich dazu brachte, darüber nachzudenken, war die SO-Frage nach einer „stripslashes()“-ähnlichen Funktion in Python.Mein erster Gedanke war „Warum nicht Ihr eigenes definieren und es einfach aufrufen, wenn Sie es brauchen“, aber es warf die Frage auf:Ist es für eine solche Funktion vorzuziehen, die interpretierte Sprache diesen Overhead bewältigen zu lassen, oder wäre es besser, eine Erweiterung zu schreiben und die kompilierte Sprache hinter dem Interpreter zu nutzen?

Answer 1

Die Grenze zwischen „interpretierten“ und „kompilierten“ Sprachen ist heutzutage wirklich fließend.Das erste, was Python beispielsweise tut, wenn es Quellcode sieht, ist, ihn in eine Bytecode-Darstellung zu kompilieren, im Wesentlichen dasselbe wie Java, wenn es Klassendateien kompiliert.Dies ist, was *.pyc-Dateien enthalten.Anschließend führt die Python-Laufzeit den Bytecode aus, ohne auf die Originalquelle zu verweisen.Traditionell würde eine rein interpretierte Sprache bei der Ausführung des Programms kontinuierlich auf den Quellcode zurückgreifen.

Beim Erstellen einer Sprache ist es ein guter Ansatz, eine solide Grundlage zu schaffen, auf der Sie die übergeordneten Funktionen implementieren können.Wenn Sie über ein solides, schnelles String-Verarbeitungssystem verfügen, kann (und sollte) der Sprachdesigner so etwas wie „stripslashes()“ außerhalb der Basislaufzeit implementieren.Dies geschieht aus mindestens mehreren Gründen:

• Der Sprachdesigner kann zeigen, dass die Sprache flexibel genug ist, um diese Art von Aufgabe zu bewältigen.
• Der Sprachdesigner schreibt tatsächlich echten Code in der Sprache, der Tests hat und somit zeigt, dass die Grundlage solide ist.
• Andere Menschen können die übergeordnete Funktion leichter lesen, ausleihen und sogar ändern, ohne den Sprachkern aufbauen oder überhaupt verstehen zu müssen.

Nur weil eine Sprache wie Python zu Bytecode kompiliert und ausgeführt wird, heißt das nicht, dass sie langsam ist.Es gibt keinen Grund, warum jemand nicht einen Just-In-Time (JIT)-Compiler für Python schreiben könnte, ähnlich dem, was Java und .NET bereits tun, um die Leistung weiter zu steigern.Tatsächlich kompiliert IronPython Python direkt in .NET-Bytecode, der dann mithilfe des .NET-Systems einschließlich JIT ausgeführt wird.

Um Ihre Frage direkt zu beantworten: Das einzige Mal, dass ein Sprachdesigner eine Funktion in der Sprache hinter der Laufzeit implementiert (z. B.C im Fall von Python) würde darin bestehen, die Leistung dieser Funktion zu maximieren.Aus diesem Grund sind Module wie der Parser für reguläre Ausdrücke in C und nicht in nativem Python geschrieben.Andererseits wird ein Modul wie getopt.py in reinem Python implementiert, da alles dort ausgeführt werden kann und die Verwendung der entsprechenden C-Bibliothek keinen Vorteil bietet.

Answer 2

Es gibt auch einen zunehmenden Trend, Sprachen, die traditionell als „interpretiert“ gelten, auf einer Plattform wie der JVM oder CLR neu zu implementieren – und dann für die Interoperabilität einen einfachen Zugriff auf „nativen“ Code zu ermöglichen.Von Jython und JRuby aus können Sie also problemlos auf Java-Code zugreifen, und von IronPython und IronRuby aus können Sie problemlos auf .NET-Code zugreifen.

In Fällen wie diesen könnte die Fähigkeit, „die kompilierte Sprache hinter dem Interpreter zu nutzen“, als Hauptmotivator für die neue Implementierung beschrieben werden.

Answer 3

Siehe den Abschnitt „Papiere“ unter www.lua.org.

Besonders Die Implementierung von Lua 5.0

Lua definiert alle Standardfunktionen im zugrunde liegenden (ANSI C) Code.Ich glaube, das hat hauptsächlich Leistungsgründe.Kürzlich, d.h.Die „string.*“-Funktionen haben eine alternative Implementierung in reinem Lua, was sich als wichtig für Teilprojekte erweisen kann, in denen Lua auf der .NET- oder Java-Laufzeitumgebung ausgeführt wird (wo C-Code nicht verwendet werden kann).

Answer 4

Solange Sie eine portable API für die kompilierte Codebasis wie die verwenden ANSI C-Standardbibliothek oder STL In C++ würde die Nutzung dieser Funktionen Sie davon abhalten, das Rad neu zu erfinden und wahrscheinlich einen kleineren, schnelleren Interpreter bereitstellen. Lua verfolgt diesen Ansatz und ist im Vergleich zu vielen anderen definitiv klein und schnell.