Closures / Lambdas /…に対するC＃、Java、Scalaのアプローチのメリットとデメリットは何ですか？

Project Lambda（JSR 335）のメーリングリストに送信されたBrian Goetzの電子メールPeek Past lambdaで表明された実装のアイデアと懸念と、C＃とScalaの技術的な実装の違いは何ですか？

メールから：

「たぶんラムダは単に内部クラスのインスタンスであるべきで、それは本当にシンプルだろう」という道を探りましたが、最終的には「関数は言語の未来にとってより良い方向である」という立場になりました。

そしてさらに：

世界のオブジェクトであるラムダは、この将来の可能性と矛盾しています。ラムダは関数の世界観ではありません。この柔軟性を維持することは、ラムダにオブジェクト性の外観でさえ負荷をかけないことを支持するポイントの1つです。

結論：

Lambdas-are-functionsはドアを開きます。Lambdas-are-objectsはそれらを閉じます。
これらのドアが開いたままになるのを好む。

また、Redditスレッドのユーザーからのコメントは次のとおりです。

私は実際にこれについてNeal Gafterにメールしました。彼の説明についての私の限られた理解では、C＃と現在のJavaデザインは、デリゲートは実際にはオブジェクトであり、関数型ではありません。JavaはC＃のラムダの短所から学び、それらを避けるべきだと彼は信じているようです（C＃がJavaの短所から学び、最初にそれらを避けたように）。

「Lambdas-are-functions」アプローチが「Lambdas-are-objects」よりも多くの機会を将来可能にするのはなぜですか？誰かがどのような違いが存在し、それらがコードの記述方法にどのように影響するかを説明できますか？

Scalaの物事が「うまくいく」ことを見て、C＃/ Java（8）で採用/提案されているアプローチについて何かが欠けていると考え続けています。

オブジェクトと関数に関する議論は、赤いニシンだと思います。質問が「ラムダは関数ですか、それともオブジェクトですか？」答えはイエスです。

それがファーストクラスの機能のポイントです。それらは他のどのタイプとも異なって扱われません。JavaはすでにObject型とプリミティブ型の違いをほとんど無視しているため（Scalaはさらに優れています）、ラムダがObjectのサブクラスであるか、新しいプリミティブ型であるか、他の何かが言語にとって重要ではありません。重要なのは、ラムダをコレクションに入れ、それらを呼び出して呼び出し、呼び出し、オブジェクトまたはメソッドのいずれかでやりたいことができることです。

Scala applyは、just ()で呼び出せるメソッドが呼び出されたラッパーオブジェクトを使用してこれを実現し、メソッド呼び出しのように見せます。これは見事に機能します。ほとんどの場合、メソッドを持っているか、関数オブジェクトの適用を呼び出しているかを気にする必要さえありません。

私が理解から、それはラムダがされている方法の詳細だと考え主要言語レベルで。メールが言うように、

現在の設計はラムダ（SAMタイプ）のオブジェクトボックスと密接に結びついていると思われるかもしれませんが、とにかく効果的にオブジェクトを作成します。しかし、これは将来的に「裸の」ラムダを検討したり、ラムダの他の変換コンテキストを検討したり、ラムダを制御構造にさらに緊密に統合したりできるように、表面から慎重に隠されています。私たちは今それをやっていませんし、そうするための具体的な計画すらありませんが、将来それを可能にする可能性はデザインの重要な部分です。

私はあなたの質問を非常にうまくまとめていると思います。「ラムダはオブジェクト」であると宣言した場合、それらは特定のクラスのオブジェクトに過ぎず、それだけに固執します。一方、「ラムダは関数」と宣言すると、意味的にはるかに豊かな競技場が得られます。Java 1.7はそれらをオブジェクトにコンパイルするかもしれないので、その時点では実質的に同一です。

ただし、Java 1.8または1.9は、関数をより柔軟な方法で使用できるようにするよりも、言語に変更（構造化された構造型など）をもたらす可能性があります。「ラムダがオブジェクト」だった場合、これらの変更には後方互換性がなく、人々の既存のコードを壊さないように、新しいコンセプトを完全に導入する必要があります。しかし、javacラムダを静かに背後のオブジェクトに変換するだけであればjavac、セマンティクスが保持されている限り、新しいものは必要なものに変換できます。

ほとんどの場合、彼は何かにあまりにも早くコミットしたくないだけです。彼が提示した消去以外の理由はわかりませんが、それは確かに非常に強力な理由です。

私は関数型が好きではありません-私は関数型が大好きです-しかし、その関数型はJava型システムの既存の側面である消去とひどく戦いました。消去された関数タイプは、両方の世界で最悪です。

Scalaのこれらのメソッドを検討してくださいRegex。

def replaceAllIn (target: CharSequence, replacer: (Match) ⇒ String): String
def replaceSomeIn (target: CharSequence, replacer: (Match) ⇒ Option[String]): String

単純に次のようにすれば、より簡単になります。

def replace (target: CharSequence, replacer: (Match) ⇒ String): String
def replace (target: CharSequence, replacer: (Match) ⇒ Option[String]): String

残念ながら、これらの2つの機能は消去下では同一であるため、それは不可能です。しかし、これらの関数はやや異なることを行うので、別の名前でも十分です。

ただし、a Matchは非常に便利なものですが、ほとんどの場合String、サブグループの一致またはリストのいずれかが必要です。これが欲しいです：

def replaceAllIn (target: CharSequence, replacer: (String) ⇒ String): String
def replaceAllIn (target: CharSequence, replacer: (Seq[String]) ⇒ String): String
def replaceAllIn (target: CharSequence, replacer: (Match) ⇒ String): String

消去のため不可能です。この特定の例を選んだ理由は、直接関与していたからですが、Stack Overflowで少なくとも半ダースの質問を見てきました。

そして、その後、ScalaのパターンマッチングとJava instanceofは消去のために事実上役に立たないと考えてください。

この問題が処理されるまで関数型を遅らせるのは公平だと思います。結局のところ、JVMにはそれを備えた言語がたくさんあり、Javaが急速に進化している言語のようではありません。