One thing that baffles me a little bit about LINQ in .NET is that it&#x27;s got a dual identity.<p>On one hand you&#x27;ve got the IEnumerable&lt;T&gt; interface, which supports the fluent syntax and is extremely easy to riff on with extension methods. (The &quot;fluent syntax&quot; itself is just a bunch of extension methods.)<p>On the other hand you&#x27;ve got the mechanisms you need to support the query syntax, which behave more like duck typing. If you implement a couple methods with certain names and signatures, not all of which are formalized by an interface, then the compiler will let you use query syntax with objects of that type. It also turns out that the stuff you need to implement are roughly the bind and return operations from a monad. . . but not exactly. In particular, the element they use in place of bind is a bit more complicated, and not in a way that adds any real expressive power. It just makes the signature a bit more irritating to support.<p>In other news, re: lack of higher kinded polymorphism - That&#x27;s something that the maintainers of F# have forcefully resisted adding to the language. The argument, which I&#x27;ve yet to take the time to look into deeply, is that typeclasses interact poorly with formal interfaces so you shouldn&#x27;t allow a language to have both. I&#x27;m a bit skepty on that one, though, since I&#x27;d assume there would be wailing coming from the Scala community if it were really that bad.