5

.Net VMの基盤についてもっと学び始めたところですが、すぐに何かに見舞われてしまいます。私は、C＃のすべての動的なものとIronX言語の実行を可能にするDLRと呼ばれるこの新しいものがあることを知っています。しかし今、私はBooと呼ばれるこの言語について読んでおり、DLRが存在するずっと前から動的な機能を備えていたようです。それで、

1）これはどうして可能ですか？

2）DLRは方程式に何を追加しますか？

3）Booのような言語は、DLRの観点からそれ自体を再実装することによって、何かを得るために立つでしょうか？

私があちこちで集めたものから、DLRは.NetでのDLサポートに必要なすべてを除外し、再利用可能な形式にしたときに、IronPythonから出てきたように見えます。だから私が推測しているのは、DLRは特別なものではなく、Microsoft.Scripting.dllのダイナミックオブジェクトを支援するライブラリだけですが、時間があれば自分でコードを作成することはできません。ブーはどうなったのかな？そして、2と3については、DLRの共通性と再利用性により、将来のDLRの改善を自動的に適用除外できると思いますが、すでにDLRを作成している場合は、DLRを使用して再実装する緊急の「必要性」はありません。独自のカスタムランタイム？または、DLRには、.Net上で実行できる何よりも優れた秘密のMSソースがありますか？

4）DLRは本当にランタイムですか、それとも単なるライブラリのセットですか？（とにかくランタイムとは正確には何ですか？この質問への答えを理解する前に、またはそれが何かを意味する質問であるかどうかを理解する前に、コンパイラ理論をさらに学ぶ必要があります。この質問は無視してください。またはしないでください。）

5）IronPythonコンパイルはどのように機能しますか？CILの新しい動的バージョンにコンパイルされますか、それともプログラムのテキストを含む文字列の前に「ironpython.exe」コマンドを追加するだけですか？うーん、動的がC＃のキーワードである場合、CILの動的バージョンが必要ですよね？では、.NetはCILでCLRとDLRのどちらを使用するかをどのように知るのでしょうか。

6）JVMのDaVinciプロジェクトは異なりますか？これは、JVM自体の実際の再実装のようです。このアプローチの意味は何ですか？パフォーマンスが大幅に向上すると思いますが、他に何かありますか？MSがこの道を選ばなかった理由は何ですか？

7）DLRは、DSLを作成するためにBooをやや時代遅れにしますか？

4

2 に答える 2

5

ここにたくさんの質問があります！すべてに答えられるかどうかはわかりませんが、できる限りのことをします。

  1. Booは、（Iron）Pythonと同じ意味で動的ではありません。これは主に静的に型付けされた言語であり、強力な型推論とpythonic構文を備えています。これは、オプションのダックタイピングと相まって、非常にダイナミックな感触を与えますが、Pythonとは確かに同じではありません。Booは、PythonよりもC＃4に似ています（構文を除く）。

  2. DLRは、CLRに加えて言語実装者の動的サポートを追加します。これは、静的に型指定された言語（VB.NET、C＃、F＃など）を対象としています。

  3. 本当に私見ではありません。IronPythonに似すぎてしまいます。Booの特徴の1つは、静的に型付けされていることです。

  4. ランタイムは、言語のいくつかの基本的な構成をサポートするライブラリです。VB.NET、C＃、F＃、Boo、それらはすべてランタイムライブラリを持っています。VB.NETまたはC＃ランタイムは、.NET Frameworkに付属しているため、通常は表示されません。エリック・リッパートからこれについてSOについて素晴らしい答えがありましたが、私はそれを見つけることができません。

  5. これについてコメントすることはできません。IronPythonの実践的な経験はあまりありません。

  6. DaVinciプロジェクトについて知らない、これについてコメントすることはできません。

  7. いいえ。私が知る限り、Booのマクロと拡張可能なコンパイラは.NET言語では非常にユニークです（Nemerleにも同様のマクロ機能があります）。BooDSLがIronPythonDSLよりも多かれ少なかれ強力であるかどうかは本当にわかりません。私が確かに言えることは、BooDSLの実装はPythonDSLの実装とは大きく異なるということです。

于 2010-12-23T02:56:27.793 に答える
4

DLRは、基本的に3つのことをパーティーにもたらします。

  • 完全なプログラムのコンパイルを可能にする式ツリーの拡張セット（LINQで最初に導入された）。これらは、ILを直接生成するよりもはるかに簡単にコードを生成する方法を提供します。これにより、無効なILを生成できる多くのケースが排除され、さらに多くのケースが簡単にデバッグ可能なランタイム例外に変わります。
  • 組み込みの呼び出しサイトキャッシュメカニズムにより、独自のメカニズムを作成する必要はありません（動的言語での優れたパフォーマンスに非常に役立ちます）。これには、マルチレベルキャッシュや、未使用のアイテムのエージングアウトなどが含まれます。
  • 動的言語が実行時に相互に通信し、呼び出し元の言語の正しい結果をネゴシエートできるようにするメタオブジェクトプロトコル（たとえば、メンバーが存在しない場合にJavaScriptで未定義を返す、動的言語に関係なくPythonでAttributeErrorをスローする）オブジェクトが書き込まれました）。

メタオブジェクトプロトコルは、絶対に共有する必要がある唯一の要素です。他のすべてのものは、自分で作成できます。

IronPythonはDLRの上に完全に構​​築されているため、コンパイルモデルは実際には式ツリーにコンパイルすることです。.NET 4.0とともに出荷されたDLR内層は、これらの式ツリーをコンパイルするために使用され、外層の一部であるインタープリターを使用して、これらの式ツリーを解釈します。解釈されたバージョンがホットになった後、式ツリーを遅延コンパイルできます。このコンパイルには、さまざまな操作（取得、メンバーの設定、オブジェクトの呼び出しなど）の動的ディスパッチに使用する呼び出しサイトの生成が含まれます。ここでもDLR（この場合は呼び出しサイトメカニズム）を使用します。IronPythonは、これらの操作に両方の標準DLRバインダーと、IronPython固有のアクション（コードコンテキストを介したフロー、*argsおよび**args呼び出しのサポートなど）を実行するカスタムバインダーの組み合わせを使用します。

Davinciプロジェクトは、CLRがすでにデリゲートの形で持っているJVMに「メソッドハンドル」を追加します。また、CLRにはなく、DLRの動作では得られなかった新しい「invokedynamic」オペコードが追加されます。代わりに、DLRは、既存のプリミティブ（デリゲート、洗練されたジェネリック）に加えて、相互運用プロトコルを定義するためのライブラリを使用します。どちらもコールサイトの概念を追加しており、それらは2つの間でかなり類似している可能性があります。

于 2010-12-23T05:12:54.247 に答える