5

Scala (少なくともJVMでは) は、Java との互換性のために型消去を使用します。この機能は、広く 受け入れ られてい ません。これを修正することは、JVM では困難です。

JVM の状況とは対照的に、.NET は具体化されたジェネリックをサポートしています。Scala の .NET 実装はそれらを使用しますか? そうでない場合、具体化を使用するとどのような問題が発生する可能性がありますか?

4

2 に答える 2

4

JVM と .NET の間で Scala のセマンティクスを壊さないように慎重に作業を進めています。

私は 2011 年に scala-tools メーリングリストでこの質問をしましたが、答えは Miguel Garcia によって与えられ、彼は全体像を概説しています:

いくつかの引用：

(1) Scala.Net プレビューの現在の機能。お気づきのとおり、消去フェーズもパイプラインの一部として実行されます。これはプレビュー バージョンの "機能" であり、CLR ジェネリックのサポートがまだ提供されていなかったため、含める必要があった "機能" です (詳細は後述)。ただし、Scala.Net で JVM スタイルの消去を実行することには大きな利点が 1 つあります。それは、CLR Generics の準備が整うのを待つ代わりに、Scala ライブラリに依存するすべての Scala プログラムを .Net 上で既にコンパイルできることです。問題の JDK API の IKVM サポートを条件として、Java JDK に依存するこれらのプログラムもコンパイルできます [1]。

(2) Scala.Net での CLR ジェネリックのサポート。それをサポートする主な動機は、既存のアセンブリとの相互運用性を得ることです。その相互運用性を得るために、Scala セマンティクスから離れないように注意が払われます。つまり、有効な Scala プログラムはすべて実行され、JVM と .NET で同じ結果が得られます。これにより、進行中の作業が始まります [2]。最初のプロトタイプは、Scala の C# サブセットのみを処理します。だから今、私は残りに取り組んでいます。当初の予想よりも多くの作業が必要ですが、言語全体をカバーすることが重要です。

.NET アセンブリとの相互運用性、特にネイティブの問題に関するいくつかのコメント。はい、CLR アセンブリは、「ネイティブ int」(異なる CPU では異なるサイズ)、.dll によってエクスポートされた C 関数の P/Invoke などを使用して表現できます。Scala.Net は、その低レベルの策略を行うことを目的としていません。関心のあるアセンブリの相互運用性は、「共通言語仕様」のレベルです。つまり、C#、VB.NET などのコンパイラから通常取得するものです (「通常」、つまり、「[DllImport]」属性と関連する C++ イズムを使用しない限り)。 ）。

CLI 仕様からの引用:

--- 引用開始 --- 共通言語仕様 (CLS) -- CLS は、言語設計者とフレームワーク (つまり、クラス ライブラリ) 設計者の間の合意です。CTS (Common Type System) のサブセットと一連の使用規則を指定します。言語は、少なくとも CLS の一部である CTS の部分を実装することによって、フレームワークにアクセスする最大の機能をユーザーに提供します。同様に、フレームワークは、公にエクスポートされた側面 (クラス、インターフェイス、メソッド、およびフィールドなど) が CLS の一部であり、CLS 規則に準拠する型のみを使用する場合に最も広く使用されます。--- 引用終了 ---

スレッド全体を参照してください：

https://groups.google.com/forum/?fromgroups#!topic/scala-tools/JDjstK1_uvM

于 2012-07-24T15:27:54.563 に答える
3

この質問の答えから、VMにジェネリックスを保持することは、表現できるものとタイプ間の関係を決定するため、まったく利点がない可能性があると考えることができます。（詳細については、Ola Biniによる元のブログにアクセスしてください）。

その他の例：

消去は、下位互換性のためだけでなく、動的型付け言語によって促進される完全な実行時型情報にはコストがかかるため、有用であるように思われます。.NET CLR Genericsの設計は、コードの特殊化によってこのコストに取り組んでいます。上記のケースは、それが消去である場合、および特定の欠点のせいにされるのが言語である場合を明確にすべきでした。

ネットネットでは、JVMがジェネリックを具体化した場合（型消去なし）、Scalaの型システムを実装することはできません... Scalaの型システムはJavaよりも複雑であり、JVMにJavaジェネリックに基づくジェネリックがあった場合はScalaではまだ問題があります。一方、型消去を使用すると、実行時にすべての型情報が利用できない場合でも、コンパイラは複雑な型システムを実装できます。

私の知る限り、Scalaの.NETバックエンドは現在のJVM実装よりもはるかに遅れており、.NETの改良されたジェネリックもサポートしていません。

Scala 2.10は、実際の仮想マシンモデルから型情報を抽象化する方向にさらに進んでいます。Martin Oderskyは、たとえばこのエントリ（42'18 "で始まる）に埋め込まれているプレゼンテーションで、新しい反射/具体化の相互作用を提示しました。

そうすれば、タイプタグ（マニフェストを置き換える）を使用して、パターンマッチングと消去の問題を克服できるようになると思います。このメーリングリストのスレッドには少しありますが、それがどの程度機能するか、または機能しないかはわかりません。

（純粋な推測:)より多くの抽象化を行うと、JVMよりも型情報がさらに少ないプラットフォームのバックエンド（JavaScriptへの架空のコンパイルなど）に役立つ場合があります。

于 2012-07-23T13:50:11.857 に答える