MicrosoftのDynamic Language Runtime(DLR)は、 Common Language Runtime(CLR)上で動作し、動的言語向けのコンピュータ言語サービス を提供します。これらのサービスには以下が含まれます。
DLRは、IronPythonやIronRubyプロジェクトなど、.NET Framework上で動的言語を実装するために使用されます。
動的言語の実装は共通の基盤システムを共有しているため、相互に連携しやすくなります。例えば、どの動的言語のライブラリでも、他の動的言語で利用できるようになります。さらに、ホスティングAPIは、 C#やVisual Basic .NETなどの静的型付けCLI言語との相互運用性も提供します。
マイクロソフトのダイナミック言語ランタイムプロジェクトは、 MIX 2007でマイクロソフトによって発表されました。[ 2 ] [ 3 ]
Microsoft は 2008 年 11 月に .NET DLR 0.9 ベータ版をリリースし[ 4 ]、2008 年 12 月に正式版 0.9 をリリースしました。バージョン 1.0 は 2010 年 4 月にリリースされました。2010 年 7 月に、Microsoft は DLR のライセンスをMicrosoft Public LicenseからApache License 2.0に変更しました[ 5 ]。同じく 2010 年 4 月に.NET 4がリリースされると、DLR は .NET Framework 自体に組み込まれました[ 6 ] 。
GitHubでホストされているオープンソースの DLR プロジェクトには、言語実装者向けの追加機能がいくつかある。2010 年 7 月のリリース後、数年間はプロジェクトでの活動がほとんどなかった。IronRuby の開発に携わった Microsoft の開発者は、これを .NET Framework 上の動的言語に対する Microsoft のコミットメントの欠如と解釈した。 [ 7 ] [ 8 ]しかし、2016/17 年以降は定期的な活動があり、多くの改善とアップグレードにつながっている。
2007年、マイクロソフトは当初、DLRを次期Visual Basic 2010(VB 10.0)およびManaged JScript(ECMAScript 3.0)に加え、PythonおよびRubyにも使用する予定でした。[ 2 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ]
DLR の Ruby と Python に関する研究は、 Ruby言語の .NET 実装であるIronRubyとIronPythonを生み出した。[ 2 ]
2009年8月までに、マイクロソフトはDLRにマネージドJScriptを実装する計画はもうないことを発表した。[ 13 ] その後、フレドリック・ホルムストロムは独自にDLR用のJavaScript実装を提供し、IronPythonやIronRubyの命名規則に倣って「IronJS」と名付けた。
C#と同様に、Visual Basic はIronPythonやIronRubyなどの DLR 上に構築された動的言語のオブジェクトにアクセスできます。[ 14 ] [ 15 ]
Windows 8でリリースされたPowerShell 3.0 は、DLR を使用するように更新されました。[ 16 ]
Schemeの実装であるIronScheme [ 17 ]は、DLR をベースに構築することを計画していました。このアイデアは、プロジェクトで使用されていたDLRブランチがトランクと同期しなくなったこと、および (プロジェクト コーディネーターによると) 当時の DLR の最新バージョンでは Scheme の要件の大部分をサポートできなかったことから放棄されました。[ 18 ]
動的言語ランタイムは、多くの動的言語に共通する特定の機能に対応するノードを持つ汎用的な言語非依存の抽象構文木の上に言語固有の機能を実装できるという考えに基づいて構築されています。 [ 19 ]このアーキテクチャは、汎用スタックに実装する必要のある基本的な言語構成要素の数が本質的に制限されるべきであるという考えに支えられています。[ 20 ] DLR は、これらのノードによって表現される機能に対応するコードを動的に生成します。DLR 上に実装される動的言語のコンパイラは、DLR 抽象木を生成し、それを DLR ライブラリに渡す必要があります。
DLR は、DynamicSiteメソッドをオブジェクトにバインドするタスクをキャッシュする動的に更新されるオブジェクトを提供します。動的言語では、オブジェクトの型や含まれるメンバーがプログラムの実行中に変化する可能性があるため、メソッド呼び出しはメソッド リストをチェックして、呼び出しが有効かどうかを確認する必要があります。DynamicSiteオブジェクトは、オブジェクトとそのメソッドの状態を表し、キャッシュします。オブジェクトへの更新は、オブジェクトにDynamicSiteも反映されます。DLR は、すべてのメソッド呼び出しをオブジェクト経由でルーティングし、オブジェクトはメソッドのDynamicSite高速ルックアップと実際の実装とのバインドを実行します。 [ 21 ]
Parrot仮想マシン(依存関係なし)やDa Vinci Machine(JavaのJVMに新しいバイトコードをJVM命令セットに追加して構築)などの他の取り組みとは対照的に、DLRは既存の共通言語ランタイム、つまり.NET Framework仮想マシンの上に構築されています。[ 22 ]
短期的には、少数の言語を使用してDLR開発の第一波を推進することに重点を置いており、開発者と緊密に直接協力してDLR設計の最大の問題点を解消します。この初期段階の後、より広範な言語コミュニティに働きかけたいと考えています。
このようなドキュメントは実際にはありませんが、一般的な目標は年末までに IronPython 2.0 を出荷することです。DLR 自体については、IronPython 2.0 とほぼ同時期に v1.0 を出荷する予定です。
1年前、チームは半分に縮小し、機敏性が著しく制限されました。[…] 全体的に見て、IronRuby、そして一般的に.NET上の動的言語に対するコミットメントが著しく欠如しているように感じます。
Studioで動作し、デザイナーと統合するための最後の後押しがなければ、両方のIron言語は恐らく死に絶えるだろう。そしてマイクロソフトは、それらを成功させる意志を失ってしまったようだ。
新しいDLRでは、IronPython、IronRuby、Javascript、そして新しい動的VBxコンパイルがサポートされています。
VB 10 は、Silverlight のダイナミック言語ランタイム (DLR) と呼ばれる機能を活用しています。
、DLR の設計 (式ツリー、相互運用性、呼び出し箇所、ホスティングなど) に情報を提供するための実験的なものでした。ASP の将来機能と Silverlight ダイナミック SDK でリリースした JS は、DLR が CLR 4.0 でのリリースに向けて進化を続けるにつれて非常に古く、使用できなくなりました。残念ながら、現時点では DLR でホスト可能な JScript を開発してリリースする予定はありません。
Basic は、IronPython や IronRuby などの動的言語のオブジェクトにバインドします。
ながら、私のDLRブランチはSilverlightブランチと大きく同期していません。今考えてみたのですが、DLR自体は必要ないかもしれません。調べてみます。問題は、DLRは現状のままでは、スキームの要件の大部分をサポートするには不十分だということです。
{{cite web}}: CS1メンテナンス: アーカイブサービスは非推奨になりました (リンク)の実装における重要なコツは、このようなツリーを使用してコードをデータとして受け渡し、コードをできるだけ長く分析しやすく変更可能な形式に保つことです。
新しい言語を実装するために必要な式ツリーノードの数には、急速に平坦化する漸近曲線が存在するという考えがある。それが事実かどうかはまだ分からない。
と JVM 拡張機能の違いは注目に値する。CLR を大幅に強化することなく、完全に CLR のレベルを超えて動作する一方、JVM とライブラリは同時に開発されている。
{{cite web}}: CS1メンテナンス: アーカイブサービスは非推奨になりました (リンク)