DLR、Boo、JVM

Question

私は .Net VM の基礎についてさらに学ぼうと試み始めたところですが、すぐに何かに戸惑ってしまいます。DLR と呼ばれる新しい機能があり、C# でのすべての動的な機能と IronX 言語の実行が可能になったことは知っています。しかし今、私は Boo と呼ばれるこの言語について読んでいます。どうやら、この言語には DLR が存在するずっと前から動的機能が備わっていたようです。それで、

1) どうしてそんなことが可能なのでしょうか?

2) DLR は方程式に何を追加しますか?

3) Boo のような言語は、DLR に関してそれ自体を再実装することで何かを得ることができますか?

私があちこちで集めた情報によると、DLR は IronPython から派生したもののようです。IronPython は、.Net での DL サポートに必要なものをすべて取り出して、再利用可能な形式にまとめたものです。つまり、DLR は特別なものではなく、Microsoft.Scripting.dll の動的オブジェクトを支援するいくつかのライブラリにすぎず、時間があれば自分でコードを作成できないものではないのではないかと私は推測しています。ブーに何が起こったのでしょうか？そして 2 と 3 については、DLR の共通性と再利用性により、将来の DLR の改善は自動的に適用されると思いますが、すでに独自のカスタムランタイム?それとも DLR には、.Net 上でできることよりも優れたものにする秘密の MS ソースがあるのでしょうか?

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

5) IronPython のコンパイルはどのように機能しますか?CIL の新しい動的バージョンにコンパイルされますか、それともプログラムのテキストが含まれる文字列の先頭に「ironpython.exe」コマンドを追加するだけですか?うーん、C# で Dynamic がキーワードであれば、CIL の動的バージョンが存在するはずですよね?では、.Net は CIL で CLR を使用するか DLR を使用するかをどのように判断するのでしょうか?

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

7) DLR により、Boo は DSL を作成するのにやや時代遅れになりますか?

Answer 1

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

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

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

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

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

Answer 2

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

1. ブーは、（鉄）pythonと同じ意味で動的ではありません。それは主に、強力なタイプの推論とPythonic構文を備えた静的にタイプされた言語です。これは、オプションのアヒルのタイピングと相まって、非常にダイナミックな感触を与えますが、Pythonと同じではありません。ブーは、Pythonよりも（構文を除く）（構文を除く）c＃4です。

2. DLRは、言語実装者に動的サポートを追加します の上に 静的にタイプされた言語（vb.net、c＃、f＃など）に向けられたCLR

3. 本当に私見ではありません。 Ironpythonに似すぎます。正確には、ブーの特性の1つは、静的に型付けされていることです。

4. ランタイム それは 言語のいくつかの基本的な構成要素をサポートするライブラリ。 vb.net、c＃、f＃、boo、それらはすべてランタイムライブラリを持っています。通常、vb.netまたはc＃runtimesは、.netフレームワークが付属しているため、決して表示されません。 Eric Lippertからこれについて素晴らしい答えがありましたが、私はそれを見つけることができません。

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

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

7. いいえ。私が知っている限り、ブーのマクロと拡張可能なコンパイラは.NET言語で非常にユニークです（ネマル 同様のマクロ機能があります）。 Boo DSLがIronpython DSLSよりも多かれ少なかれ強力であるかどうかは本当に言うことができません。確かに言えることは、boo dslsの実装は 大きく異なります Python DSLSの埋め込みから。