Collections.Seq
モジュールに、で宣言された拡張メソッドと同等のように見えるメソッドがたくさんあるのはなぜSystem.Linq.Enumerable
ですか?F#の設計者が、.NETにすでに存在するものを再利用するのではなく、これらすべてに新しい名前空間と新しい/異なる名前を作成する必要性を感じたのはなぜですか?
(追加のメソッドが必要な場合、なぜそれらを追加しなかったのSystem.Linq.Enumerable
ですか?)
Collections.Seq
モジュールに、で宣言された拡張メソッドと同等のように見えるメソッドがたくさんあるのはなぜSystem.Linq.Enumerable
ですか?F#の設計者が、.NETにすでに存在するものを再利用するのではなく、これらすべてに新しい名前空間と新しい/異なる名前を作成する必要性を感じたのはなぜですか?
(追加のメソッドが必要な場合、なぜそれらを追加しなかったのSystem.Linq.Enumerable
ですか?)
LINQメソッドはSystem.Core=>にあるため、.NET 3.5以降でのみ使用でき、F#ベースライブラリは.NET2.0以降をサポートします。
(パイプラインを介した)Seq関数の追加の使用スタイルは、LINQ列挙可能拡張のドットスタイルよりもF#コードの方が自然です。
ここに他のいくつかのまともな答えがありますが、私の見解は簡単です
基本的に、F#のイディオムに慣れると、.NET APIがF#スタイルのプログラミングにやさしいことに気付くでしょう。F#は、パイプラインスタイルのプログラミング(最後のカレー引数として着信シーケンスの部分適用を必要とする)と型推論(オーバーロードとの相互作用が悪い)に重点を置いています。
したがって、F#には、F#とうまく連携する独自のライブラリがあります。(これが急ごしらえのデコーダーリングのブログです。)
もう1つの理由は、F#でパイプライン演算子(|>、<|、>>)を使用することです。
.NET拡張メソッドは、基本的に最初の引数の部分適用を提供します。F#パイプライン操作者は、最後の引数に部分的に適用されます。Seqモジュールのすべての関数は、最後の引数としてシーケンスを取ります。
C#
seq.Where(...)
.Select(...)
.Take(...)
F#
seq
|> Seq.filter ...
|> Seq.map ...
|> Seq.take ...