Java 8で関数型を削除する理由

JDK 8 Lambda Expert Group（EG）がJavaプログラミング言語に新しい関数タイプを含めないことにした理由を理解しようとしています。

メーリングリストを調べると、関数型の削除に関する議論のスレッドが見つかりました。

文の多くは私にとって曖昧です。おそらくコンテキストがないためであり、場合によっては型システムの実装に関する知識が限られているためです。

ただし、このサイトで安全に定式化できると思われるいくつかの質問があり、それらの意味をよりよく理解するのに役立ちます。

_{メーリングリストで質問をすることはできますが、スレッドは古く、すべての決定がすでに下されているので、私は無視される可能性があります。とりわけ、これらの人がすでに計画で遅れていることがわかります。}

関数型の削除をサポートし、SAM型の使用を推奨するという彼の答えで、Brian Goetzは次のように述べています。

具体化なし。関数型を具体化することの有用性について長いスレッドがありました。具体化しないと、関数の型はぐらついています。

彼が言及しているスレッドが見つかりませんでした。今、私は、構造関数型の導入がJavaのほとんど名義型システムに特定の複雑さを暗示しているかもしれないことを理解できます。理解できないのは、具体化されたSAM型の具体化の違いです。

彼らは両方とも同じ具体化の問題の対象ではありませんか？関数型が具体化の観点からパラメータ化されたSAM型とどのように異なるかを誰もが理解していますか？

別のコメントで、ゲッツは次のように述べています。

タイピングには、名義型と構造型の2つの基本的なアプローチがあります。名義のアイデンティティはその名前に基づいています。構造型のアイデンティティは、それが構成されているものに基づいています（「int、intのタプル」または「intからfloatへの関数」など）。ほとんどの言語は、ほとんど名義的またはほとんど構造的です。「辺り」を除いて、名義型と構造型をうまく組み合わせた言語は多くありません。Javaはほぼ完全に名義です（いくつかの例外を除きます：配列は構造型ですが、下部には常に名義要素型があります;ジェネリックには名義型と構造型も混在しており、これは実際には多くのソースの一部ですジェネリックに関する人々の苦情の報告。）構造型システム（関数型）をJavaに移植する s名義型システムは、新しい複雑さとエッジケースを意味します。関数型の利点はこれだけの価値がありますか？

型システムの実装の経験がある方。彼がここで言及しているこれらの複雑さやエッジケースの例を知っていますか？

正直に言って、JVMに完全に基づいているScalaのようなプログラミング言語が、基盤となるプラットフォームの具体化の問題があっても、関数やタプルなどの構造型をサポートしていると考えると、これらの申し立てに混乱します。

誤解しないでください。関数型はSAM型よりも優れているべきだと言っているのではありません。彼らがこの決定をした理由を理解したいだけです。

SAMのアプローチは、実際にはScala（およびC ++ 11）が匿名関数（Scalaの=>演算子またはC ++ 11の[]()（ラムダ）構文で作成された）で行うことといくらか似ています。

Java側で最初に答える質問は、ラムダステートメントの戻り値の型を、またはなどの新しいプリミティブ型にするintかbyte、何らかのオブジェクト型にするかです。Scalaで、存在しないいかなるプリミティブ型は-偶数の整数は、クラスのオブジェクトであるIntと機能は全く異なっていない、クラスのオブジェクトである- Function1、Function2関数がとる引数の数に応じて、等、及び。

C ++ 11、ruby、およびpythonも同様に、明示的または暗黙的な方法で呼び出し可能なオブジェクトを返すラムダ式を持っています。返されたオブジェクトには#call、関数として呼び出すために使用できる標準メソッドがいくつかあります。たとえば、C ++ 11では、オブジェクトの呼び出しメソッドの呼び出しがテキスト形式でも関数呼び出しのように見えるようにstd::functionオーバーロードする型を使用します。 :-)operator()

Javaの新しい提案が煩雑になるのは、構造型付けを使用して、そのようなメソッドを別のオブジェクト（別の名前のComparator単一のメインメソッドを持つオブジェクトなど）に割り当てることです。これはいくつかの点で、概念的に不快ですが、それはありません結果のオブジェクトは、コールバック、コンパレータを表現するためにオブジェクトを取る既存の関数に渡される、というように、と明確に定義されたシングルを呼び出すことができることを期待することができることを意味しますまたはなどのメソッド。このようなコールバックオプションはすべて同じ方法で呼び出し可能であり、したがってC ++ 11ラムダを使用できるようにSTLを調整する必要がないため、C ++のトリックはC ++ 11よりも前にきちんとこの問題を回避しました。#compare#callbackoperator()sort等々。過去にそのようなオブジェクトに標準の命名法を使用していなかったJava（おそらく、オペレーターのオーバーロードのようなトリックが単一のアプローチを明らかにしなかったため）はそれほど幸運ではないため、このハックは多くの既存のAPIを変更する必要がない。