Nice questions. There is a lot of depth and opportunity for speculation in the first one in particular.

Is the implementation code available?

Yup. Since F# 1.1.7.x, the full source code is available for F#, AbsIL and ILx. I've been able to rebuild the entire product on my servers without ((significant)) incident. A few of the builds had one or two minor targeting issues, but those were easy to determine. Anything more significant than that and I would likely raise the issue with fsbugs <(at)> microsoft.com. Please see Performing a local build of F#, AbsIL and ILx.

I think F# is a great alternative for us interested in functional languages

I tend to think of mixed functional/imperative/OO in a static-typed language as the strong point. I don't see it as an "alternative", but rather as a tool (which is what I think you are saying). I think that is your point on the rich .NET library issue. I can use F# where and when it provides value and advantage. Where that is not the case, I can use C#, VB.NET or other tools within the .NET suite.

But, I'm a little worried about Microsoft Research pulling the plug on further development.

The language is now in the wild. The reality here is straightforward. MSFT/MSR will ultimately decide the fate of this language on their terms in their time frame. But to that end, MSFT is a for-profit corporation. If the opportunity to sell large hunks of server licenses to entities that want high-performance computing environments on .NET exists, F# is likely one considerable entry point into that space. .NET is not considered a platform of consideration in many HPC/Grid opportunities at the moment. Given recent works (Chad's article on F# in Grid computing, quant finance/banking firms consuming large grid resources, increases in big pharmaceutical companies purchases when buying lots of modeling HPC equipment to reduce the costs of R&D of product), I think there is opportunity.

But that opportunity is in the "anonymous" stage, i.e. the market has not been recognized, has not been made a prospect, has not been made a qualified buyer and has not been sold this proposition. The risk here is that this opportunity remains unfulfilled. Relative to MSFT's total revenue, I can't venture a guess on the estimated size of markets where F# would provide advantage. If those estimates are available through IDC/Gartner or elsewhere, I can only imagine whether they have made it internally to the appropriate people within MSFT.

I think F# as a general-purpose language will take significant marketing and recognition of the cost to "tool-up" so that the language is consistent across all .NET products, e.g. winforms, webservices, xml serialization, etc. and anywhere where there is a code generator or other facility that has been built for the other .NET languages. These are not insignificant, but the Developer Division has a history of immersion and adoption, i.e. if F# is brought in as a Developer Division language, it will be given the traditional resources to make it pervasive in every manner. Any deficiencies in an adoption plan would mean that the opportunity for revenues in any sales in any channel would be subject to those deficiencies and put sales/ server licenses at risk. I'm not in that division, but there is a payoff curve and I believe that the position of a language as a core component has risk/payoff structure that is different when measured in relative terms to a product like Commerce Server or BizTalk or other MSFT products.

Also, I was wondering why labels (named parameters) and option arguments (I assume that means default arguments) are not in the language?

Named parameters suck. The End.

Ok, just kidding on that one. I agree, but I think that the ability to perform ad-hoc polymorphism (overloading) is in direct conflict with the usage of optional arguments (and Don will gladly correct me if I have misstated this ;) ).

I for one use R as a Math language and love the optional parameters with default values that I can name on the fly when using stuff. But I don't see the lack of named/optional parameters as an impediment in the usage of F#. Matching, discriminated unions and other tools can be used effectively to manage the equivalent issues that arise when considering the flexibility of named/optional parameters. Currying is also an effective tool when constructing stuff.

I was curious if anybody knew the intermediate-long term plans for F#?

((Getting out crystal ball)). Yup, it's still too cloudy. I think that the F# team will likely continue in their current works until there is movement and interest on the MSFT side of things.