既にインタープリターを持っているのに、動的言語 (Python、Perl など) に Parrot のように VM を使用する必要があるのはなぜですか? 自分のコードと自分のマシンの間で異なる VM を使用し、別のインタープリターを使用することによって、潜在的に何を得ることができますか?
(私は VM の問題に慣れていないので、答えは明らかです)
編集
既にインタープリターを持っているのに、動的言語 (Python、Perl など) に Parrot のように VM を使用する必要があるのはなぜですか? 自分のコードと自分のマシンの間で異なる VM を使用し、別のインタープリターを使用することによって、潜在的に何を得ることができますか?
(私は VM の問題に慣れていないので、答えは明らかです)
編集
既にインタープリターを持っているのに、動的言語 (Python、Perl など) に Parrot のように VM を使用する必要があるのはなぜですか?
まず、プロジェクトを開始する場合、まだインタープリターを持っていない可能性があります。
ただし、インタープリターがあり、それに機能を追加するか、Parrot を使用するように書き直すかを検討していると仮定すると、考えられるトレードオフは次のとおりです。
個人的には、Parrot のオプティマイザ (および主に最適化を容易にするためのレジスタ ベースの設計) と十分にテストされたクロス プラットフォーム コードベースは、私を納得させるのに十分です。
ASCII ソース コードの解析が遅い。ソース ファイルが一度解析されてから、インタープリターがバイナリ構造を使用すると、より高速になります。Python では、この構造を.pyc
ファイルに保存して、再利用を高速化します。
次の 2 つの手順があります。
これは、たとえば scala で使用されます。scala-VM はありません。Scala は単なる新しい構文です。scala コンパイラは Java バイト コードを作成します。