インタープリタ言語 - インタプリタの背後にあるコンパイル言語を利用する

Question

言語設計者 (または単に知識のある人) がいる場合は、インタープリタ型言語の標準ライブラリを作成する背後にある方法論に興味があります。具体的には、何が最善のアプローチだと思われますか?標準関数/メソッドをインタープリタ言語で定義するのか、それともインタープリタが記述されたコンパイル言語でそれらの呼び出しの処理を実行するのか?

私がこれについて考えるようになったのは、Python のstripslashes() のような関数に関する SO の質問でした。最初に考えたのは、「独自に定義して、必要なときに呼び出すだけではどうでしょうか」ということでしたが、次のような疑問が生じました。このような関数の場合、インタープリター言語にそのオーバーヘッドを処理させる方が望ましいでしょうか、それとも拡張機能を作成してインタープリターの背後でコンパイル済み言語を利用する方が良いでしょうか?

Answer 1

最近では、「解釈された」言語と「コンパイルされた」言語の間の境界線が非常に曖昧になっています。たとえば、Python がソース コードを認識すると最初に行うことは、それをバイトコード表現にコンパイルすることです。これは、Java がクラス ファイルをコンパイルするときに行うことと本質的に同じです。これは *.pyc ファイルに含まれるものです。次に、Python ランタイムは元のソースを参照せずにバイトコードを実行します。従来、純粋に解釈された言語は、プログラムの実行時にソース コードを継続的に参照していました。

言語を構築するときは、より高レベルの機能を実装できる強固な基盤を構築するのが良いアプローチです。堅牢で高速な文字列処理システムがある場合、言語設計者は、基本ランタイムの外部で、stripslashes() のようなものを実装できます (実装する必要があります)。これは少なくともいくつかの理由から行われます。

• 言語設計者は、その言語がその種のタスクを処理できるほど柔軟であることを示すことができます。
• 言語設計者は実際にその言語で実際のコードを作成します。テストが含まれているため、基礎がしっかりしていることがわかります。
• 他の人は、言語コアを構築したり理解したりする必要がなくても、より簡単に上位レベルの関数を読み、借用し、さらには変更することができます。

Python のような言語がバイトコードにコンパイルされて実行されるからといって、それが遅いという意味ではありません。パフォーマンスをさらに向上させるために、Java や .NET がすでに行っていることと同様に、Python 用のジャストインタイム (JIT) コンパイラを作成できない理由はありません。実際、IronPython は Python を .NET バイトコードに直接コンパイルし、JIT を含む .NET システムを使用して実行します。

あなたの質問に直接答えると、言語設計者がランタイムの背後で言語で関数を実装するのは唯一の場合です (例:Python の場合は C) は、その関数のパフォーマンスを最大化することになります。正規表現パーサーなどのモジュールがネイティブ Python ではなく C で記述されているのはこのためです。一方、getopt.py のようなモジュールは純粋な Python で実装されます。これはすべてそこで実行でき、対応する C ライブラリを使用する利点がないためです。

Answer 2

また、これまで「インタープリター型」と考えられてきた言語を JVM や CLR などのプラットフォームに再実装し、相互運用性を確保するために「ネイティブ」コードに簡単にアクセスできるようにする傾向も増えています。そのため、Jython と JRuby からは Java コードに簡単にアクセスでき、IronPython と IronRuby からは .NET コードに簡単にアクセスできます。

このような場合、「インタプリタの背後でコンパイル言語を活用する」機能が、新しい実装の主な動機と言えるでしょう。

Answer 3

次の「論文」セクションを参照してください。 www.lua.org.

特に Lua 5.0の実装

Lua は、基礎となる (ANSI C) コードですべての標準関数を定義します。これは主にパフォーマンス上の理由によるものだと思います。最近、つまり「string.*」関数は純粋な Lua での代替実装を取得しました。これは、Lua が .NET または Java ランタイム上で実行される (C コードが使用できない) サブプロジェクトにとって重要であることがわかります。

Answer 4

コンパイルされたコードベースにポータブル API を使用している限り、 ANSI C標準ライブラリ または STL C++ の場合、これらの関数を利用すれば、車輪の再発明が不要になり、より小型で高速なインタプリタが提供される可能性があります。 ルア このアプローチは、他の多くのアプローチと比較して間違いなく小さくて高速です。