Почему модуль Collections.Seq в F # в основном переопределяет все методы расширения Enumerable?

Question

Почему в модуле Collections.Seq есть много методов, которые кажутся эквивалентными методам расширения, объявленным в System.Linq.Enumerable? Почему разработчики F # почувствовали необходимость создать новое пространство имен и новые / разные имена для всех них вместо повторного использования того, что уже существует в .NET?

(Если им нужны были какие-то дополнительные методы, почему они просто не добавили их в System.Linq.Enumerable?)

Answer 1

Некоторые другие достойные ответы здесь, но я кратко

• частичное применение (методы .NET объединены, методы F # каррированы)
• перегрузка (методы .NET перегружены, значения F-let не могут быть)

По сути, как только вы привыкнете к идиомам F #, вы обнаружите, что API .NET отчасти подходят для программирования в стиле F #. F # в значительной степени ориентирован на программирование в стиле конвейера (которое требует частичного применения входящей последовательности в качестве последнего аргумента curry) и на вывод типа (который плохо взаимодействует с перегрузкой).

Так что F # имеет свою собственную библиотеку, которая хорошо работает с F #. (Вот кольцо быстрого вызова декодера blog .)

Answer 2

Поскольку методы LINQ расположены в System.Core =>, доступны только в .NET 3.5 и более поздних версиях, а базовая библиотека F # поддерживает .NET 2.0 +.

Дополнительный стиль использования функций Seq (через конвейер) более естественен для кода F #, чем стиль точек расширений LINQ Enumerable.

Answer 3

Еще одна причина заключается в использовании операторов конвейера (|>, <|, >>) в F #.

.NET Extension Methods в основном обеспечивает частичное применение первого аргумента.F # pipelining oprators частично применяется для последнего аргумента.Все функции в модуле Seq принимают последовательность в качестве последнего аргумента.

C #

seq.Where(...)
   .Select(...)
   .Take(...)

F #

seq
|> Seq.filter ...
|> Seq.map ...
|> Seq.take ...