During the last months, I started to collect some readings (academic publications and books) that one should check out, as he learns functional programming. These are life changing readings (other pretty fundamendal, other very specific), and can be studied in a time frame of several months or more, so unless you are a doctoral researcher on the field of programming languages, take your time and enjoy.
[ 1] J. V. Eijck and C. Unger, Computational Semantics with Functional Programming, 1st ed. Cambridge University Press, 2010.
[ 2] R. Bird, Pearls of Functional Algorithm Design, 1st ed. Cambridge University Press, 2010.
[ 3] D. Vytiniotis and P. Jones, “Let should not be generalized,” in Proceedings of the 5th ACM SIGPLAN workshop on Types in language design and implementation, pp. 39–50, 2010.
[ 4] F. Kirchner and C. Munoz, “The proof monad,” Journal of Logic and Algebraic Programming, 2010.
[ 5] A. Filinski, “Monads in action,” in Proceedings of the 37th annual ACM SIGPLAN-SIGACT symposium on Principles of programming languages, pp. 483–494, 2010.
[ 6] J. Gibbons and B. C. Oliveira, “The essence of the Iterator pattern,” Journal of Functional Programming, vol. 19, no. 3, pp. 377–402, 2009.
[ 7] G. Hutton, Programming in Haskell. Cambridge University Press, 2007.
[ 8] C. McBride and R. Paterson, “Applicative programming with effects,” Journal of functional programming, vol. 18, no. 01, pp. 1–13, 2007.
[ 9] R. K. Dyvbig, S. P. Jones, and A. Sabry, “A monadic framework for delimited continuations,” Journal of Functional Programming, vol. 17, no. 06, pp. 687–730, 2007.
[10] P. Wadler and P. Thiemann, “The marriage of effects and monads,” ACM Transactions on Computational Logic (TOCL), vol. 4, no. 1, p. 32, 2003.
[11] B. C. Pierce, Types and Programming Languages, 1st ed. The MIT Press, 2002.
[12] B. Mcadams, “Y in practical programs,” 2001.
[13] G. Hutton, “A tutorial on the universality and expressiveness of fold,” Journal of Functional Programming, vol. 9, no. 4, pp. 355–372, 1999.
[14] S. Finne, D. Leijen, E. Meijer, and S. P. Jones, “Calling hell from heaven and heaven from hell,” in Proceedings of the fourth ACM SIGPLAN international conference on Functional programming, pp. 114-125, 1999.
[15] J. Palsberg and C. B. Jay, “The essence of the visitor pattern,” COMPSAC-NEW YORK-, pp. 9–15, 1998.
[16] G. Hutton and E. Meijer, “Monadic parsing in Haskell,” Journal of functional programming, vol. 8, no. 04, pp. 437–444, 1998.
[17] G. Huet, “The zipper,” Journal of Functional Programming, vol. 7, no. 05, pp. 549–554, 1997.
[18] H. Abelson and G. J. Sussman, Structure and Interpretation of Computer Programs - 2nd Edition, 2nd ed. The MIT Press, 1996.
[19] G. Hutton and E. Meijer, “Monadic parser combinators,” Journal of Functional Programming, vol. 8, no. 4, pp. 437–444, 1996.
[20] P. Wadler, “Monads for functional programming,” Advanced Functional Programming, pp. 24–52, 1995.
[21] E. Meijer and G. Hutton, “Bananas in space: Extending fold and unfold to exponential types,” in Proceedings of the seventh international conference on Functional programming languages and computer architecture, p. 333, 1995.
[22] P. Wadler, “Monads and composable continuations,” Lisp and Symbolic Computation, vol. 7, no. 1, pp. 39–55, 1994.
[23] G. L. Steele Jr, “Building interpreters by composing monads,” in Proceedings of the 21st ACM SIGPLAN-SIGACT symposium on Principles of programming languages, p. 492, 1994.
[24] J. M. Hill and K. Clarke, An introduction to category theory, category theory monads, and their relationship to functional programming. Citeseer, 1994.
[25] P. Jones, L. Simon, and P. Wadler, “Imperative functional programming,” in Proceedings of the 20th ACM SIGPLAN-SIGACT symposium on Principles of programming languages, p. 84, 1993.
[26] P. Wadler, “The essence of functional programming,” in Proceedings of the 19th ACM SIGPLAN-SIGACT symposium on Principles of programming languages, p. 14, 1992.
[27] D. J. King and P. Wadler, “Combining monads,” Functional Programming, Glasgow, pp. 134–143, 1992.
[28] A. W. Appel, Compiling with Continuations. Cambridge University Press, 1991.
[29] E. Moggi, “Notions of computation and monads,” Information and computation, vol. 93, no. 1, pp. 55–92, 1991.
[30] E. Meijer, M. Fokkinga, and R. Paterson, “Functional programming with bananas, lenses, envelopes and barbed wire,” in Functional Programming Languages and Computer Architecture, pp. 124–144, 1991.
[31] O. Danvy, J. Koslowski, and K. Malmkjær, “Compiling monads,” TechnicalReportCIS-92-3, Kansas State University, Manhattan, Kansas, 1991.
[32] P. Wadler, “Comprehending monads,” in Proceedings of the 1990 ACM conference on LISP and functional programming, pp. 61–78, 1990.
[33] E. Moggi, “An abstract view of programming languages,” 1989.
[34] J. Hughes, “Why functional programming matters,” The computer journal, vol. 32, no. 2, p. 98, 1989.
[35] P. Wadler and R. Bird, “Introduction to functional programming,” pp. 1--14, 1988.
[36] E. Moggi, “Computational lambda-calculus and monads,” 1988.
[37] G. L. Steele Jr and G. J. Sussman, “Lambda: The ultimate imperative,” AIM-353, 1976.
[38] G. L. Steele Jr, “Lambda: The ultimate declarative,” AIM-379, 1976.
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.
