First thing’s first. If you’re interested in an in depth description of the changes to F# in the 2010 beta and the May CTP, look no further than this post by Don Syme. Clearly, the F# team has been busy:
After parsing the above notes and spending a little time with the new version of F#, here are my early impressions.
Vastly Improved Visual Studio Integration
The September CTP version of F# featured some Visual Studio integration, but it was very buggy. The Error List often contained false positives after compiling a project. Errors from background compilation were lacking as well. With the new release, both Visual Studio 2008 and 2010 Beta 1 see huge improvements in both of these areas.
With the new release, the difference has been night and day. Background compilation updates the error list swiftly, and all the errors that I’ve seen so far have been legitimate. Better Visual Studio integration was a clearly a big, if not the biggest goal of this release, and the good news is that the F# team seems to have nailed it.
There is still some work to be done before I’d say that the environment is ideal, but it’s great to have these improvements since this was an area of weakness in the September CTP release. I need a good reason to play with the updated debugger integration, but the team has indicated that there are some improvements there, too.
Although it’s not getting as much attention as, this is one of the most notable changes in this release. According to Don Syme’s post, sequence expressions, tail calls, and other areas should see increased performance. I haven’t had time to crunch numbers, but I have already observed a big performance increase when running Paint Wars. With the previous CTP release, I was only able to crunch about 75 blobs at one time. With no other changes to the code besides updating to use the new CTP, I’m able to crunch at least twice as many. Thanks to these performance improvements, I’m looking forward to finally being able to finish the F# version of Paint Wars.
I suspect that most of the performance gains come from this tidbit from Don Syme’s post:
“Sequence expressions are now compiled to state machines, instead of as a collection of API calls. This results in improved performance of F# code which works with seq. Many of the Seq.* library functions also have improved performance as a result of this change”
Since the Seq library functions form the backbone of a lot of the F# code that I write, I’m definitely excited about this change.
Standard Library Naming Conventions
Performance improvements are nice, but I am also really happy about (most) of the name changes to the F# Standard Library. Prior to these changes, it was unclear what the best practices for naming were. Should the .NET guidelines be followed? If so, why doesn’t the F# library follow them? Now, the picture is starting to get a little bit clearer.
Per Don Syme’s blog:
“The naming conventions adopted for the F# library are as follows:
o All .NET and F# OO code uses PascalCase according to existing .NET guidelines
o The F# functional programming operators such as List.map are for use in F# internal implementation code. This kind of code uses camelCase for operator names
o Underscores should not be used except for the Module.to_type and Module.of_type pattern. In Beta1 you will only see underscores for this pattern “
Although these changes might not seem that exciting, I think that it is really important to see consistency across the standard library since it has such a large influence on the way the F# community writes code.
Support for custom numeric types (123X, 1.0R, etc.)
This looks pretty cool. I’d like to look into this in more depth and blog about it later. I’m not sure that there are a ton of uses for this, but it seems like a feature that could be abused in a good useful fun way.
Miscellaneous Small (but good) Improvements
These are some other things that I thought were good additions, but they don’t warrant much discussion:
- #light as default – Good. Almost all F# code I’ve ever seen began with #light
- Support for calling and exposing .NET ParamArray parameters (‘params’ in C#) – This is convenient. It was annoying to have to package values up as arrays so that they would work with params array functions.
- F# uses .NET 4.0 tuple, BigInt, Lazy types – Also good. It’s the correct thing to do.
The addition of Array.Parallel functions is exciting. Unfortunately, for some reason, the same functionality was not provided for Seq. It would definitely be nice to see the F# team provide a Seq.Parallel that integrates with the Parallel Extensions in .NET 4.0. Writing F# style wrappers over PLINQ functions is straightforward to do, but it should be a part of the Standard Library. I imagine that this will happen soon, though.
Renaming _right to Back
In short, Fold_right and Scan_right have been renamed to FoldBack and ScanBack. Fold and Scan are the “_left” variants.
I won’t dwell on this one since it is a matter of personal preference, but I don’t like it at all. I understand why the change was made. “Back” might even be a better way to describe the behavior of these functions. The problem is that the “right/left” naming of these functions was already well defined and established in the functional world. This looks like one of those cases of Microsoft trying to make something less confusing to the average Joe that results in lots of parenthetical comments and ultimately more confusion.
No New PowerPack Release
This one stinks because I was relying on the SI module for units of measure in Paint Wars. Unfortunately, the September CTP version of the Power Pack can’t be used since binaries are not compatible between the two releases. I ended up having to copy and paste the SI module into my project from the CTP source.
I would wager that a new Power Pack release is not far off. However, considering that the Power Pack is supposed to release more frequently than the core library, it is irritating that a new Power Pack not included in this release.
Update: The PowerPack has been released for 2010 Beta1 http://www.microsoft.com/downloads/details.aspx?FamilyID=e475a670-9596-4958-bfa2-dc0ac29b4631&displaylang=en
Still Can’t Click and Drag To Reorder Files in Solution Explorer
This is a minor oversight, but with all the work to better integrate F# with Visual Studio, I was hoping the team would catch this one. To reorder .fs files in the Solution Explorer, you still have to right click and select “move item up” or “move item down” (remember, in F# projects, file order matters). I was recently reminded of how nice it would be to be able to click and drag to reorder files when I discovered that “Add Existing Item” adds files to the bottom of the project. I had to do the right click, “move item up” dance about 15 times. Minor, yes. Annoying, definitely.
Difficult to work with same project in both 2010 and 2008 CTP
The PaintWars solution contains an XNA project which doesn’t appear to be compatible with Studio 2010 Beta 1. Before I realized this, I tried to open the solution in the 2010 beta which upgraded my .fsproj. When I tried to open the same project in Visual Studio 2008, I ran into problems since the FSharp.Core assembly was pointed at the 4.0 version and the compiler was switched to the 4.0 version as well. This is not a bug, but it’s worth warning that you have to stick with either the 2008 version or the 2010 version unless you want to maintain two .fsproj files.
Remove References to System.Threading If Using the June CTP of the Task Parallel Library
This isn’t F# specific, but since many people use F# for parallel processing, I figured that I should mention this. If you had a project that used the June 2008 CTP of the Task Parallel Library, be sure to remove the reference to the System.Threading .dll when you upgrade to .Net 4.0. I was using a couple PLINQ functions, and since PLINQ is now included in the .NET 4.0 core libraries, the F# compiler will complain with overload errors if you don’t remove the reference.
For example, using the IEnumerable.AsParallel() method results in the following, potentially confusing, error:
Error 1 The method ‘AsParallel’ is overloaded. Possible matches are shown below (or in the Error List window)
Removing the reference to System.Threading, makes everything better. Of course, you have to keep the reference if you’re using Visual Studio 2008