8

私はPyPyプロジェクトに本当に興味がありますが、その目的の最初の(しかしあまり知られていない)目的のために以下にリストされています:

  • 通訳言語のインタプリタを実装するためのツールのセット
  • このツールチェーンを使用したPythonの実装

次のブログ投稿では、 http //morepypy.blogspot.com/2011/04/tutorial-writing-interpreter-with-pypy.html 、およびhttp://morepypy.blogspot.com/2011/04/tutorial-part -2-adding-jit.html RPythonを使用してbrainforkインタープリターを実装し、JITを追加する方法に関する詳細なチュートリアルがあります。

ただし、RPythonの操作は面倒な場合があることを他の場所で読んだことがあります。動的型付け用に作成された構文は、推測される静的型付けに突然制限され、コンパイルエラーがわかりにくくなります。

だから私の質問は、上記のチュートリアルのようにブレインファッジインタプリタ/ JITを書くことを可能にする他のプロジェクトはありますか?それとも、PyPyが簡潔にそうするための唯一のオプションですか?

(余談ですが):存在する場合、RPythonの一般的なポイントは何ですか?サブセットPythonをタイプセーフにし、Pythonをそのサブセットに実装できることを示すだけですか?既存のインタプリタ作成ツールで「PyPy」を実行する方が理にかなっているでしょうか。

4

1 に答える 1

10

ただし、RPythonの操作は面倒な場合があることを他の場所で読んだことがあります。動的型付け用に作成された構文は、推測される静的型付けに突然制限され、コンパイルエラーがわかりにくくなります。

構文についてではなく(Python構文が入力と関係しているのは、型注釈の場所がないことだけです。これは、3.0では変更される可能性があります)。

  1. 良いエラーメッセージは非常難しいものであり、コンパイラの残りの部分が変更されると、それらのコードはほとんど避けられないものになります。したがって、これは多大な労力を要し、一般の人々ではなく、少数の専門家(多くの場合、翻訳者を書いたのと同じ人)によって書かれた非常に複雑なコードコンパイルコードに取り組んでいるときに最初に切り詰めるコーナーの1つです。トランスレータの動作が通常のコンパイラとはまったく異なるという事実も役に立ちません。
  2. すべてが推測されるという事実は、(読者としてのあなたにとって)型への唯一の洞察は、翻訳者が型を推測するプロセスを理解し、精神的に適用することから来ることを意味します。そして、それは通常のコンパイラ技術とはかなり異なり、正確に些細なことではありません。

だから私の質問は、上記のチュートリアルのようにブレインファッジインタプリタ/ JITを書くことを可能にする他のプロジェクトはありますか?それとも、PyPyが簡潔にそうするための唯一のオプションですか?

インタプリタからJITコンパイラを作成しようとする他のプロジェクトを私は知りません。PyPyの連中がやったとき、このアイデアは新しいものだったと私はかなり確信しているので、このようなもの(存在する場合)がRPythonよりも成熟している可能性は低いです。個々の側面を支援する多くのプロジェクトがあります。オウムのように、これらの側面の多くまたは「すべて」に一緒に取り組むものもいくつかあります。しかし、AFAIKには、PyPyほど説得力のあるサクセスストーリーはありません。

Parrotは動的言語用のVMであり、いくつかのバックエンドを備えており(私が学んだように、v1.7以降はJITはありませんが、アーキテクチャでは透過的に再導入できます)、言語実装者向けの豊富なツールセットが成長したようです。CLRとJVMは、静的オブジェクト指向言語に対して同様のサービスを提供しますが、Parrotほど洗練されたツールについては知りません。

ただし、インタプリタを作成する代わりに、それはAM(実際にはいくつか)を定義し、あなたの仕事はそのIRに言語をコンパイルすることです(そしてVMが理解できる用語で組み込み機能を定義します)。この点で、インタプリタを作成するRPythonアプローチとは異なります。また、他のVMと同様に、言語の一部の側面がIRにうまくマッピングされていない場合は問題が発生します。VMのサービスとは根本的に異なるものが必要ですか?それをエミュレートすることを楽しんでください(そしてひどいパフォーマンスに苦しんでいます)。言語固有の最適化が必要ですか(これは任意のIRには無効であり、事前に実行することはできません)。これらのパフォーマンスの向上に別れを告げます。おもちゃの言語を除いて、Parrotでの完全な言語実装を知りません。そして、彼らは常にパフォーマンスを自慢しているわけではないので、

LLVM(他の人が言及している)や他の多くのコードジェネレーター/バックエンドは、1つの要素にすぎません。インタプリタではなく、言語をマシンコードの抽象化レベルまで下げる本格的な静的コンパイラを作成する必要があります。それは実現可能かもしれませんが、確かにまったく異なります。

存在する場合、RPythonの一般的なポイントは何ですか?

「JITコンパイラーを書くのは難しいです。インタープリターを書いて買い物に行きましょう。」おそらく、「PythonでPythonを実行したいのですが、遅すぎて、プログラミング言語を最初から作成したくない」ということから始まったのでしょう。しかし、最近では、RPythonはそれ自体が非常に興味深いプログラミング言語です。これは、JITコンパイラーをファーストクラス(実際にはファーストクラスの関数という意味ではありませんが、十分に近い)言語構造として使用する世界初のプログラミング言語であるためです。 。

既存のインタプリタ作成ツールで「PyPy」を実行する方が理にかなっているでしょうか。

メタであり、調査を行い、それが機能することを示すためだけに、私は現在のアプローチを支持します。JITジェネレーターが機能するまでは、静的コンパイル、C風のパフォーマンスの可能性、マクロ(または「翻訳の側面」と呼ばれるものを追加する別の方法)を備えた任意の言語で同じものを使用できましたが、これらはまれです。 。しかし、Python言語全体に対してパフォーマンスの高い(JITであろうとなかろうと)コンパイラーを作成することは、人間が行うには難しすぎることが繰り返し証明されています。インタプリタを作成してから、別のJITコンパイラコードベースでそれを正しく実行し、それでも何でも最適化するの苦労することは、これ以上意味がなかったと思います。

于 2012-08-25T23:45:08.330 に答える