Inside F#

As a developer on the F# team, I spend a bit of my time working on the F# project system, so I wanted to briefly share a few new features and bug fixes in the latest release of F#.  Today's blog entry is mostly screenshots to call out features you might not otherwise be aware of.

First, if you right click on a file in the Solution Explorer and select Properties, you'll see that files now have a 'Copy to Output Directory' property:

This is useful for example when you want to drop a data file next to your .exe file (as suggested by the screenshot).

Next, if you right click and select Properties on a Reference node, the 'Copy Local' and 'Specific Version' options are there, which enable more control over how references are found and deployed.

Also, whereas previous versions of F# had bugs that prevented most uses of 'Solution Folders', now you can use them to organize your projects:

Finally, the prior release of F# had a number of bugs when it came to building/rebuilding solutions with multiple projects.  Symptoms included:

• 'Build' would sometimes re-build even when things were up-to-date
• 'Rebuild' would sometimes build the same project multiple times
• Build/Rebuild would sometimes spuriously fail for no obvious reason

How embarrassing!  Fortunately the latest release of F# fixes these issues.  Now you can build with confidence!  :)

One of the improvements in the latest release of F# involves the way that F# data types appear inside the Visual Studio debugger.  For example, here's a screenshot from F# 1.9.6.2 (the old version) that shows how that version displayed F# data types like lists and discriminated unions:

Can you interpret the information in the "Locals" window?  Yikes.  Clearly there were improvements to be made.

Well, now that I have just installed F# 1.9.6.16 (the new version) on my box, here's what I see:

What a difference!  Now it's easy to see the values in the list and discriminated union.

(Eagle-eyed readers may also notice the absence of #light in the second screenshot - #light is now the default.  For more details of changes, see the release notes.)

This blog entry highlights just one of many improvements in the latest release of F#.  I hope to find the time to write about more new features and improvements in the coming days and weeks... in the meantime, I hope you download the new bits and enjoy!

With the new release of F#, you have a few alternatives for grabbing these new bits to play with the latest F#:

• Install Visual Studio 2010 Beta1.  F# is now one of the core languages "in the box"!  Choose this option if you want to use the new stuff in VS2010 and .Net 4.0 and can afford the huge download/install. (Applications written in F# in VS2010 Beta1 target .Net 4.0 Beta1.)
• Install the F# May 2009 CTP Update for VS2008 (msi).  This installs the latest F# bits atop your existing VS2008 (or VS2008 integrated shell) installation.  Choose this option if you want to update F# without having to download & install VS2010 Beta1. (Applications written in F# using these bits target .Net 2.0/3.0/3.5.)
• Download the F# May 2009 CTP Update for VS2008 (zip).  This contains the F# redist, including things like the compiler (fsc.exe), the interactive command-line tool (fsi.exe), and the code library (FSharp.Core.dll).  Choose this option if you don't have VS or are using mono.  (Applications written in F# using these bits target .Net 2.0/3.0/3.5.)

You definitely want to check out the release notes for this release, as it has answers to many frequently asked questions.  Don's blog also gives a good overview of the release.

Note that if you have a previous version of F# installed, you will need to uninstall it before installing the May 2009 CTP Update.  (You can install VS2010 Beta1 side-by-side with an F# CTP.)

If you've used F# before, you may be curious about the most likely breaking changes (upgrade risks).  F# 1.9.6.16 binaries (the new release) are incompatible with F# 1.9.6.2 binaries (the prior release), so all code must be recompiled.  There are some revisions to the language and library relative to the prior CTP, but in our testing, source code migrates extremely smoothly/easily (e.g. often with no source changes, just lots of warnings about deprecated library functions that have been renamed to something else).  One exception is the Array.sort function, which previously sorted 'in place', but now, for regularity with the rest of the library, returns a fresh array (the 'in place' version has the new name Array.sortInPlace).  The other noteworthy bit is that if you rely on the PowerPack, you should wait to upgrade to VS2010 Beta1 until we publish the updated (1.9.6.16) PowerPack for .Net 4.0 Beta1 (due to some minor snags, it's not online yet; hopefully very soon).  (For those using the CTP Update, the PowerPack binaries are included in that distribution, so you're good to go today.)  By all means, if you have specific questions about migrating your code to this latest release of F#, ask questions on the Q&A sites I mentioned in a prior blog entry.

New with this release: for the first time F# has some documentation on MSDN.  (At the time of this posting, there is a minor known bug in the walkthroughs where the code snippets all have extra leading whitespace.  Since F# is whitespace-significant by default, be sure to delete this leading whitespace when copying snippets.)  These new docs are another good F# reference, as well as a resource for getting started with the language.  The F# samples on the MSDN Code Gallery have been updated; these samples are another way to get started with the language by checking out some code.

Enjoy!

It's mid-May now, which means it's been more than 8 months since we released the first CTP of F# in early September 2008 (F# 1.9.6.2).  We've seen continually strong download numbers for that release, and the F# user base continues to grow.  I love it; it is great to be working on a product that so many people are enjoying (as well as a product that is making people more productive!). 

Since the last release, a ton of great content (blogs, Q&A, videos, etc.) about F# has been published on the web, and so I decided to summarize my favorite online content for learning F#.  Of course, the very first link you need is the Microsoft F# Developer Center, as it has well-organized links to much of the content listed below.  But I have my own favorites, so here they are.

Videos

Luca's An Introduction to Microsoft F# video from PDC2008 is fantastic - I can't say enough good things about it.  If you want the overview talk of what F# is all about, as well as the chance to watch someone build an F# app and talk about the main syntax/features/etc, then grab a comfy chair and sit back and watch this terrific presentation.

There is also a good recent video posted on Channel 9 of Don talking about F# and demoing a number of F#'s interactive features.

The Microsoft F# Dev Center has links to more videos about F#.

Q&A

If you've got questions about F#, the F# community has answers!  There are two terrific Q&A sites for getting your F# questions answered:

• hubFS is billed as "THE place for F#" - a Q&A forum devoted entirely to F#
• StackOverflow is a site for all kinds of programming questions, and you'll find many F# questions and answers there

Both sites have a strong readership, and the time between posting an F# question and receiving a useful answer is often measured in mere minutes.

One StackOverflow question is worth calling out: "Getting started with F#", as it is very apropos for this blog entry.

My blog

Of course my own blog entries are among my favorites.  :)  For reference, here is a list of my own blog entries that I think will be useful to people learning F#:

• The basic syntax of F# - keywords and constructs
• The basic syntax of F# - classes, interfaces, and members
• The basic syntax of F# - types
• F# function types: fun with tuples and currying
• Discriminated unions in F#
• Pipelining in F#
• What does this C# code look like in F#? (part one: expressions and statements)

(For a more complete overview of F#, you may consider checking out (or contributing to) the F# Wikibook.)

Blogs by Microsoft people

Many of the people who work full time on F# have blogs:

• Don Syme's blog
• Brian McNamara's Inside F# (you are here!)
• Chris Smith's blog
• Luke Hoban's blog
• Jomo Fisher's Sharp Things

Additionally there are some other MS people who also blog a bit about F#:

• Andrew Kennedy's blog
• Luca Bolognese's blog
• Dustin Campbell's Did it with .NET

There is a ton of content on the web regarding F#; here's a great aggregated feed of F# content:

• Planet F# feed

That's all for now - I hope you find these links helpful!

This blog entry describes a useful idiom for coding a set of effects that need 'commit-or-rollback' semantics.

Overview

Often times when you're writing code, you have objects that need to maintain some invariants among two or more pieces of mutable state.  When you do an operation with a side-effect, you may need to update more than one piece of state in a way that preserves the invariant.  Since some sub-operations may fail (e.g. with exceptions), you have to be careful to ensure the invariants are preserved even if the face of a failure mid-stream.  Often times this means 'undo'ing some effects to return to the original state.  The stuff I am talking about is a lot like transactions, e.g. 'atomic' and 'consistent', with 'commit-or-rollback' semantics.

When the 'effects' are just changing values of variables, it is easy to 'undo' these effects - just change the variable back to its original value.  But sometimes effects cannot be un-done.  If I paint the walls of my bedroom blue, and then I decide I don't like the color, I can't simply click 'undo' to get back to the previous state of the world.  (It sure would be handy if I could!)  However I can do a 'compensating action' to bring me back to the original state - namely, I can paint the walls again, back to the original color.

Similar kinds of 'non-undo-able' effects happen in software.  If I call Dispose() on an IDisposable, this cannot be undone.  (But I might be able to create a new object in the same state as the one I just Dispose()d.)  If I delete or rename a file on the file system, I may not be able to simply 'undo' these actions (but one can imagine possible 'compensating actions' to return the filesystem to its original state).  To sum up, there are times when you may find you need to 'effectively-undo' certain actions by performing other 'compensating' actions.  But it can be non-trivial to write code that does this correctly.

Example

Let's consider a contrived and silly example to make this more concrete.  Suppose I get a new job offer I want to take.  I need to quit my old job, move into my new office and paint the office walls my favorite color, and fill out all the usual new-job paperwork.  The catch is, some of these operations may fail and revoke the job offer.  So if I quit my old job before I actually get the new job finalized, I need to go beg for my old job back as a 'compensating action'.  And if I paint the walls of my new office before the new job paperwork is committed, I may have to paint the walls back to the original color as compensating action.

To model this in a simple program, I will just print out the commentary of what is happening.  Here's some sample C# methods that implement the actions and compensations I described:

Now the goal is to glue these bits together into a program with one of these three possible outputs...

...depending on whether certain phases fail. In the first case, everything succeeds, in the second case, trying to paint the walls fails, and in the third case, the failure happens when completing the job paperwork.  So how would you implement it in C#?

Here is one possible way:

This is straightforward - for each action that can possibly fail, we surround it with a try-catch and in the catch block we do any necessary compensating actions before re-throwing the exception.  This works, but the code is a bit of a mess; when you face a similar situation with real code (rather than all these one-liner function calls) it can become very hard to reason about all the paths through the code to ensure everything works correctly.

A better abstraction

What we need is a handy way to group actions with their compensations and the failure semantics.  It turns out that with a suitable method which I'll call "Transactional.Do", we can rewrite the code like this:

What a difference!  21 lines of code in the original example were reduced to 4 lines of code here.  Let's take a closer look at this; here's the definition of the "Transactional" class:

Check out the body of the main 'Do' method; it encompasses the general logic of what we need.  Namely, if after completing some action, later actions fail, then we need to 'undo' the original effect by running a compensation.  If everything succeeds, or if things fail before we have even done the original effect, then there is nothing to undo; in the former case, we 'commit' the result, whereas in the latter case nothing happened yet.  (The last two overloads just deal with the annoyance that 'void' is special in C# and you need overloads to deal with both Action<Arg> (when there is no return value) and Func<Arg,Result> (when there is); practically every C# API that uses Action/Func needs to have multiple overloads like this.)

With this handy little class, it becomes easy to write short, correct, readable code with transactional effects.

Commentary, and looking forward

This strategy has some limitations in C#, but is nonetheless an effective way to deal with cases where you have a number of sequential effects that need transactional semantics (either everything successfully commits, or else everything 'rolls back' to the original state) where each effect has its own 'undo' compensation.  I am interested to hear comments/feedback on the approach, as I don't recall seeing it before, but in retrospect it seems to me like an obviously useful thing.

It also happens that Transactional.Do has the right signature to be the 'Bind' of a monad, and so in a future blog entry I'll show how to capture this abstraction in F# using computation expressions, and hopefully show how the F# syntax sugars overcome some of the limitations you'd have in C# (I say 'hopefully' because I haven't worked out all the details fully yet myself).