Yesterday I watched the live 3:30 PM: Languages Panel session, with Eric Lippert, Luke Hoban and Mads Torgersen and the niner Charles Torre, through (http://www.msteched.com/), provided by Channel9 live (http://channel9.msdn.com/). This wasn’t just a live panel, but an interactive QnA too, so as me and a friend / colleague of mine (Nikos), watched it, we asked a question through twitter of Channel9 (http://twitter.com/ch9live). The question (both actually) have been presented through the monitor, to the panel and was answered briefly (check screenshots). The following, are food for thought to everyone and anyone who would like to participate in a conversation about Types in C#, F#, Scala, Java, etc, provide clarifications or error corrections in the way I perceived the answers or else :):)
Mads Torgersen seemed pretty sure and his initial reaction was original when answering the question! A bright “No”, from the member of the C# Language, designer group (he was speaking of his main domain of work, C#).
Take LINQ for example, he said. LINQ is hardwired in the compiler, providing of this query pattern of composed Select, Where, From, … etc clauses, that provide a single type of computation, over our data. How can one, express through type system, such compositions? The answer is Higher Kind Types. Mads said, that providing such functionality to the C# programmer, would be pretty confusing. There would be rare cases, that one would like to define higher kind types[1], thus this capability (a concept coming from languages like Haskell btw), is not included in future plans currently.
LINQ construct is in general following the monadic [2] programming model. In contrast, F#, being a functional programming language and giving features like computational expressions for asynchronous programming, would be able to provide such level of abstraction if needed in the future. As I understood from what Luke Hoban said, this is 
more “easy” in F#, as during the design process, such monadic constructs are already implemented in a general way by the F# language design group, hence, this could be exposed in the future.
The live panel, continued the conversation with very interesting topics, such as Rx, but when the “pure” word came up, I couldn’t resist posting another (and much more impulsive) question, that was answered live very quickly, from the panel.
Luke immediately took action and said that, many people are very active with Haskell inside the MS group, but currently isn’t any movement for incorporating .NET with a pure functional language, due to the incompatible paradigm of current .NET with FP. .NET is a chaos of libraries, doing so many things, providing ways of side effect-“ing” so much, that a pure functional language couldn’t fit in. However ideas from this whole class of functional languages, could migrate in the future, towards F#.
Mads noted something pretty accurate. Purity is also a programming style. This very same concept is very useful as a C# style too. Minimizing side effects, approaches this way of thinking, and we can simulate this in our own way (in a local manner). Mads, also said that this could be the way of .NET library transformation over the years, but not instantly.
I would like to thank the panel, for providing such elaborate answers! Keep up the very good work, providing us such expressive languages!!
[1] Kind is to a type what a type is to a value (I don’t think this is accurate, but it will do the job for now). So, conceptually, we have objects in the bottom. Objects are distinguished by types and types are classified by kinds. Starting again from bottom, objects are known at run time, types must be known at compile time and the kinds are specified by the language itself. Java 5 and C# 2.0 introduced first order parametric polymorphism, thus abstracting over types. The resulting type constructor cannot be further abstracted, however. In a generic way, you can say I want a list of T, where T is int... . So in List<T>, how would it be to abstract over that and specify through a parameter the List too via a Container[T] parameter for example? Thus we could parameterize more (abstract) List<T>, instantiating an M<T, Container> with int and List and getting List<int> or ArrayList<Customer>. So I have the M which takes a type and returns a type. Monads are generalized via this way in Haskell (check Simon Peyton Jones’ words here).
[2] Monad in simple words is a way (strategy), of combining computations to build other computations.
