Why does F#’s Collections.Seq module basically reimplement all the Enumerable extension methods?

Question

Why does the Collections.Seq module have lots of methods that appear to be equivalent to extension methods declared in System.Linq.Enumerable? Why did the designers of F# feel the need to create a new namespace and new/different names for all of these instead of reusing what already exists in .NET?

(If they needed some extra methods, why didn’t they just add them to System.Linq.Enumerable?)

Answer 1

Because LINQ methods are located in System.Core => are available only on .NET 3.5 and higher and F# base library supports .NET 2.0+.

Additionaly usage style of Seq functions (through pipeline) is more natural for F# code that dot style of LINQ Enumerable extensions.

Answer 2

Another one reason is using pipeline operators (|>, <|, >>) in F#.

.NET Extension Methods is basicaly provides partial application for first argument. F# pipelining oprators partial applies for last argument. All functions in Seq module takes sequence as last argument.

C#

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

F#

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

Answer 3

Some other decent answers here, but my take is briefly

• partial application (.NET methods are tupled, F# methods are curried)
• overloading (.NET methods are overloaded, F# let-bound values cannot be)

Basically, once you're accustomed to F# idioms, you'll discover that the .NET APIs kind of suck for F#-style programming. F# is heavily geared towards pipeline-style programming (which requires partial application of the incoming sequence as the last curried argument) and type-inference (which interacts badly with overloading).

So F# has its own library which works well with F#. (Here's a quickie decoder-ring blog.)