I’m going to look at two ways of combining F# and WPF. I’ll be using the Chart control from WPF Elements as my main example, but a lot of what I talk about here is equally applicable to any other WPF control, built-in or third-party.

Solution 1: Hybrid C# and F# Solution

The traditional way of using F# in a WPF application is to put the F# code into a class library, then invoke that class library from a C# or Visual Basic WPF application. This works very easily — a C# application can call a F# class library just as easily as it can a C# class library, with full intellisense and debugging and everything else you’d expect.

For this example, I’m going to keep the F# class library very simple. In reality, you probably wouldn’t create a separate class library for something this basic. F# really starts to shine when you’re doing a bit more processing on your data, but to keep things simple I’m not going to do much more than download it.

The data I’m going to use is the London Borough Profiles from the Windows Azure Datamarket. This is dead easy to use in F# 3.0 thanks to the OData type provider:

open Microsoft.FSharp.Data.TypeProviders
 
type Boroughs = ODataService<"https://api.datamarket.azure.com/GreaterLondonAuthority/LondonBoroughProfiles/">
 
let dataContext = Boroughs.GetDataContext()
dataContext.Credentials <- System.Net.NetworkCredential(YourUserName, YourAccountKey)

For my view model, I want to extract just a subset of this data, so I define a couple of F# types to surface it:

open System.Collections.Generic
 
type BoroughInfo = {
  Area : string
  MaleLifeExpectancy : float
  FemaleLifeExpectancy : float
  Employment : float
}
 
type ViewModel = {
  Boroughs : List<BoroughInfo>    // not BoroughInfo list -- see below
  National : BoroughInfo
}

These are F# immutable record types. We don’t need to modify the data, so immutable types are easier to write and we don’t need to muck around with all that tedious INotifyPropertyChanged stuff. The view model is going to include a list of entries for individual boroughs, plus a ‘dummy’ borough representing national averages so I can display them alongside the per-borough data.

One gotcha is that the WPF Elements charting DataSeries expects an IList as its ItemsSource. The F# list type doesn’t implement IList, so we have to be sure to make ViewModel.Boroughs a BCL List instead of a F# list.

Now we can build our view model:

let (national, boroughs) =
  dataContext.LondonBoroughProfiles
  |> Seq.filter (fun r -> r.MaleLifeExpectancy20072009.HasValue && r.FemaleLifeExpectancy20072009.HasValue)
  |> Seq.map (fun r -> { Area = r.Area; MaleLifeExpectancy = r.MaleLifeExpectancy20072009.Value; FemaleLifeExpectancy = r.FemaleLifeExpectancy20072009.Value; Employment = r.EmploymentRate2009.Value })
  |> Seq.toList
  |> List.partition (fun b -> b.Area = "National Comparator")
 
let viewModel = { Boroughs = List<_>(boroughs); National = List.head national }

Most of this should be self-explanatory — we are downloading all the borough data from the data context provided by the OData type provider, filtering out a couple of containers that don’t have data, and mapping away the nullable values. (We could have done some of this using F# query expressions, but it’s not worth it for this data set.) The only thing that may be unfamiliar is List.partition, which splits a list into two lists, the first containing things that satisfy the predicate and the second containing things that don’t. The assignment therefore puts the ‘National Comparator’ pseudo-borough into the ‘national’ list, and the real boroughs into the ‘boroughs’ list.

The end result of all this is a value called ‘viewModel’ of type ViewModel, and we can now consume this from a C# application:

// Code-behind for MainWindow.xaml -- or of course you could automatically
// wire it up using Caliburn Micro.
 
public partial class MainWindow : Window
{
  public MainWindow()
  {
    InitializeComponent();
 
    DataContext = Data.viewModel;
  }
}

<e:Chart Margin="12">
  <e:LineSeries ItemsSource="{Binding Boroughs}" XBinding="{Binding Area}" YBinding="{Binding MaleLifeExpectancy}" SeriesBrush="Navy" />
  <e:LineSeries ItemsSource="{Binding Boroughs}" XBinding="{Binding Area}" YBinding="{Binding FemaleLifeExpectancy}" SeriesBrush="Red" />
  <e:LineSeries ItemsSource="{Binding Boroughs}" XBinding="{Binding Area}" YBinding="{Binding Employment}" YAxisTitle="Employment (%)" SeriesBrush="Green" />
  <e:Chart.XAxis>
    <e:ChartAxis LabelRotation="90" LabelStep="1" MajorTickSpacing="1" />
  </e:Chart.XAxis>
  <e:Chart.YAxis>
    <e:ChartAxis Minimum="65" Maximum="90" Title="Life Expectancy (yr)" />
  </e:Chart.YAxis>
  <e:Chart.AlternativeYAxes>
    <e:ChartAxis Minimum="50" Maximum="100" Title="Employment (%)" />
  </e:Chart.AlternativeYAxes>
</e:Chart>

Solution 2: All F# Solution

With F# 3.0, though, it’s now feasible to build WPF applications entirely in F#, without needing to put the user interface into C#. In practice I know most readers of this blog will probably feel more at home in C# than in F# so they’ll want to use F# only for the core data processing anyway — but I think it’s interesting to know how F# 3.0 enables XAML support, plus there are a couple of things that may not be quite so obvious! (This example is based on Steffen Forkmann’s WPF Designer for F# announcement, which is in turn based on Johann Deneux’ XAML type provider.)

The first thing we need to do is create a Windows Application F# project. There isn’t a template for this, but we can take our class library project, go into Properties > Application, and change the Output Type to Windows Application (and add a Program.fs file to contain the application code). Or we can create a new F# Application project and change the Output Type from Console Application to Windows Application.

Next we need the XAML type provider. This is available as a NuGet package from the FSharpx folks. Right-click the F# project, choose Manage NuGet Packages, search for FSharpx.TypeProviders and click Install. (Learn more about FSharpx here.)

We also need to add references to the WPF assemblies (WindowsBase, PresentationCore, PresentationFramework and System.Xaml) and to the WPF Elements DLL.

The last piece of plumbing we need is to handle the licensed controls in WPF Elements. Copy the licenses.licx file from the WPF Elements Sample Explorer to the F# project directory, include it in the F# project and set its Build Action to Embedded Resource.

Now we’re ready to roll, where by ‘roll’ I mean create an actual WPF window.

Right-click the project and choose Add New Item. There’s no XAML template but just choose XML File and change the file extension to .xaml, e.g. MainWindow.xaml. Replace the contents of the .xaml file with the following:

<Window xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        xmlns:e="clr-namespace:Mindscape.WpfElements.Charting;assembly=Mindscape.WpfElements"
        Title="MainWindow" Height="500" Width="900">
 
  <e:Chart>
    <e:LineSeries ItemsSource="{Binding Boroughs}" XBinding="{Binding Area}" YBinding="{Binding MaleLifeExpectancy}" SeriesBrush="Navy" />
    <e:LineSeries ItemsSource="{Binding Boroughs}" XBinding="{Binding Area}" YBinding="{Binding FemaleLifeExpectancy}" SeriesBrush="Red" />
    <e:LineSeries ItemsSource="{Binding Boroughs}" XBinding="{Binding Area}" YBinding="{Binding Employment}" YAxisTitle="Employment" SeriesBrush="Green" />
    <e:Chart.XAxis>
      <e:ChartAxis LabelRotation="90" LabelStep="1" MajorTickSpacing="1" />
    </e:Chart.XAxis>
    <e:Chart.YAxis>
      <e:ChartAxis Minimum="65" Maximum="90" />
    </e:Chart.YAxis>
    <e:Chart.AlternativeYAxes>
      <e:ChartAxis Minimum="50" Maximum="100" Title="Employment" />
    </e:Chart.AlternativeYAxes>
  </e:Chart>
 
</Window>

One little nasty to watch out for: the F# XAML type provider currently handles only ‘clr-namespace’ namespaces. So we have to refer to the Mindscape.WpfElements.Charting namespace by name, instead of using the URI. Other than that this is the same XAML as in the C# application.

Finally we need to write some code to launch this window and associate it with our view model. In C#, the project template handled this for us but in F# we need to do it ourselves. Fortunately all the hard work is done by the XAML type provider:

open System
open System.Windows
open FSharpx
 
type MainWindow = XAML<"MainWindow.xaml">  // creates the MainWindow type from the MainWindow.xaml file
 
let loadWindow() =
  let window = MainWindow()  // creates a new instance of MainWindow
  window.Root.DataContext <- Data.viewModel
  window.Root
 
[<STAThread>]
(new Application()).Run(loadWindow())
|> ignore

You can now build and run the application, and you’ll find it works just like the C# one. Of course, it has taken a bit more effort to set up, but that’s a one-off, and you can now enjoy using F# for your interaction logic as well as your business logic.

You can download the source for the F# WPF Elements demo project here. You will need Visual Studio 11 Beta, and a copy of Mindscape WPF Elements (download the free edition including a 60-day trial of the charting controls). (To run the program, you’ll also need to sign up for the free London Borough Profiles data set on Azure Datamarket.) If you have any questions or problems, post in the comments or the support forum!

In the meantime, here are the slides and code samples from the ‘How to Not Write a For Loop’ talk:

• Download slides (PowerPoint 2010 format)
• Download samples (LIMITED EDITION DIRECTOR’S CUT featuring deleted samples and NEVER BEFORE SEEN out-takes)

And don’t forget that if you attended Codemania then we’re offering you a free copy of Web Workbench Pro.

1. The Option type

Tony Hoare, the inventor of the null reference, called it his ‘billion dollar mistake.’ Null is a disaster because it means that every reference type has a magic value that will destroy your program. For value types, we now have ‘normal’ value types and nullable value types to express the difference between, say, ‘this function returns an integer’ and ‘this function might return an integer, or it might not.’ But we don’t have that for reference types.

F# provides the Option type to distinguish between ‘there definitely is a value’ and ‘there might or might not be a value.’ F#’s Option is a bit like Nullable but can be used with any type, value or reference, and comes equipped with helper functions and pattern matching support. Here’s an example of Option in use:

let names = [ "alice"; "bob"; "carol"]
let name = List.tryFind (fun s -> length s < 4) names  // returns an Option
match name with
| Some n -> printfn "%s has a short name" n
| None   -> printfn "They all have long names"

Notice that if we erroneously try to use the option returned from List.tryFind as if it were a real string, the error is caught at compile time:

let names = [ "alice"; "bob"; "carol"]
let name = List.tryFind (fun s -> length s < 4) names  // returns an Option
printfn "%s has a short name" name  // Error! Expected string but got string option

In C#, the ‘not found’ case would be represented by null, and the compiler would not be able to catch the potential error.

The FSharpx project provides some helpers to make it easy to use the F# Option type from C#, though it’s of limited use except in interop because the C# compiler still won’t stop you using nulls even in non-optional situations.

2. Immutable record types

Immutable types are a great way to improve the correctness of programs. Any type that represents a value, rather than an entity which needs to preserve identity as its attributes change, should be immutable. Even quite complex objects, such as expression trees in LINQ or syntax trees in Roslyn, benefit from immutability. Unfortunately, C# makes it far more effort to write immutable types than mutable ones. Here’s two ways to implement a 2D Point type in C#, one mutable (wrong!) and one immutable (right!):

public class MutablePoint {
  public double X { get; set; }
  public double Y { get; set; }
}
 
public class ImmutablePoint {
  private readonly double _x;
  private readonly double _x;
 
  public ImmutablePoint(double x, double y) {
    _x = x;
    _y = y;
  }
 
  public double X { get { return _x; } }
  public double Y { get { return _y; } }
}

The safe, immutable type is more than twice as long!

Contrast this with F#:

type Point = { X : float; Y : float }

It’s short, it’s immutable and as a special wonder bonus it’s got proper value equality built in for free. And I want it in C#, pronto.

3. Object expressions

Object expressions are a great feature for when you want to implement an interface or override a class member without going to the trouble of spinning out an entire class or subclass for it. This can dramatically reduce the amount of code particularly when you need to capture local variables for your implementation or override. (If you’re familiar with Java’s local classes, object expressions are a lot like that.) Here’s an example using the LightSpeed IAuditInfoStrategy interface:

// blame takes a string and returns an IAuditInfoStrategy
let blame x = {
  new IAuditInfoStrategy with
    member this.Mode = AuditInfoMode.Custom
    member this.GetCurrentUser() = x }

In C#, I would have had to write out a ScapegoatingAuditInfoStrategy class with a field to hold the blamee and a constructor to pass the blamee into the class. In F#, I just told the compiler to make me an IAuditInfoStrategy that always blamed x, and it did. I often end up writing lots of little classes to capture small nuggets of code or fragments of state, and it would be great if C# had something like object expressions to make it easier.

More about object expressions here.

4. Partial application

I actually like C# lambda syntax more than F#. This is just as well, because I have to write a lot more lambdas in C# than I do in F#. The reason is that in F# I can use a trick called partial application to reuse a ‘normal’ function just with particular arguments. Let’s see an example.

Suppose I want to double every element in a sequence. I can do that using the LINQ Select operator, or its F# equivalent Seq.map:

// C#
var doubled = values.Select(v => v * 2);
// F#
let doubled = Seq.map (fun v -> v * 2) values

C# code is more concise than F# code, right? Not so fast! In F# we can partially apply the * function and save ourselves writing the lambda!

let doubled = Seq.map ((*) 2) values

Of course you can do this with your own functions too:

let isDivisibleBy x y = y % x = 0
let evens = List.filter (isDivisibleBy 2) values  // rather than (fun v -> isDivisibleBy 2 v)

Partial application reduces the amount of lambda noise in the code, and can also be useful in creating new functions by specialising existing ones. You can read more about partial application in this series and (more concisely) in this article.

5. Pattern matching

I’ve written extensively about pattern matching elsewhere, and it’s too big a topic to explain thoroughly here. Pattern matching allows you to combine programming by cases (like a switch statement) with custom logic (like an if statement) and decomposing composites to get the bits you’re interested in (like a series of property accesses or collection operations). It’s also extensible using active patterns, which means you can build classifiers independently of the routines that use the classification. And patterns compose far more conveniently than imperative code.

One often-overlooked but very powerful feature of pattern matching is that it can be used in a let statement. This allows you to effectively return multiple values from a function without having to create a XxxResult type or explicitly picking apart a tuple. Combined with the F# compiler being able to silently translate C# out-parameters into tupled return values, this creates some neat, readable idioms:

let dict = new Dictionary<string, string>()
let (found, result) = dict.TryGetValue("alice")
 
// C# equivalent
var dict = new Dictionary<string, string>();
string result = null;
bool found = dict.TryGetResult("alice", out result);

There’s much more to pattern matching than this, including recursing over lists, visiting over class hierarchies (discriminated unions), working safely with options, type-checking and casting, and, well, the list goes on. I use pattern matching all the time in F# and I always miss it when I have to come back to C# and write imperative (if-style) code to distinguish between cases.

5 1/2. Async

F#’s async workflows make it easy to write asynchronous code in a readable, easy to understand, top-to-bottom way. This is compelling — so compelling, in fact, that a similar feature is going to be adopted into C#. F# still has a bunch of async features that haven’t made it into C#, notably async agents, but for the core scenario C# programmers no longer need to be envious!

And there’s more

There’s so much in F# that would be a huge boon for C# that I could easily have made this a top 10 list. Some of F#’s features can be used from C# (read Mauricio Scheffer’s great post on ’10 reasons to use the F# runtime in your C# app’) but a lot of the features I miss are part of the language. For example, I’d love to see F#-level type inference in C#. After all, which one of these declarations do you find easier to read?

// C#
public static IEnumerable<TResult> Map<TSource, TResult>(this IEnumerable<TSource> source, Func<TSource, TResult> selector) { ... }
// F#
let map selector source = ...  // F# infers types and generic type parameters from implementation

Or how about recursive iterators? Or an interactive prompt in Visual Studio, so you could try out snippets or run demos without having to build a console or NUnit project? (Roslyn has a C# Interactive window, but Roslyn’s still some way off!) And looking to the future, F# type providers open up a whole new order of expressiveness beyond standard code generation techniques.

So what’s in your top 5? What F# features do you miss when you go back to C#?

But F# type providers can create any kind of type, and they don’t need to consult an external resource to do it. This means a type provider can be used to automagically replace repetitive boilerplate code with a simple declaration.

Consider a vector maths library. Users will want to be able to create vectors with various numbers of dimensions — 2D vectors, 3D vectors, etc. And they might even want to be able to create vectors with the same number of dimensions but different names (for example, Horizontal/Vertical instead of X/Y). In C#, you’d have to write out each vector type by hand. In F# 3, you can ship a Vector type provider, and users can create their desired vector types from that:

type Vector2D = Vector<"X", "Y">
type Vector3D = Vector<"X", "Y", "Z">
type VectorHV = Vector<"Horizontal", "Vertical">
 
let v1 = Vector2D()
v1.X <- 100.0
v1.Y <- 200.0
let v2 = VectorHV()
v2.Horizontal <- 300.0
v2.Vertical <- 400.0

Each of the created types is a real compile-time type, with type safety enforced by the F# compiler. For example, if the type provider supplies a dot product operation with vectors of the same kind (only), the F# compiler will check that the user doesn’t take dot products between vectors of different kinds:

let v1 = Vector2D()
let v2 = Vector2D()
let vh = VectorHV()
 
let v1v2 = v1.DotProduct(v2)  // okay
let v1vh = v1.DotProduct(vh)  // type checks

The created vector types work exactly as if you had written them longhand, but without all the effort, and without the limitation of having to guess what types your users will need.

Implementing a type provider

The F# team have indicated that they’ll be shipping the source for some sample type providers soon, which will include some handy helpers which should rather simplify the process of writing type providers, but for now it’s still not too difficult to implement type providers directly against the interfaces. Here’s an outline, albeit with plenty of rough edges.

The first thing you need to do is create a F# 3.0 library project. At the moment, this requires the Visual Studio 11 preview (the full version, not the Metro apps version). And you’ll need to apply TypeProviderAssemblyAttribute to that library:

[<assembly: TypeProviderAssembly>]
do ()

Next, you’ll need to implement the type provider class itself. This is a normal F# class which implements the ITypeProvider and IProvidedNamespace interfaces, and has the TypeProviderAttribute:

[<TypeProvider>]
type VectorProvider() =
  interface ITypeProvider with // ...
  interface IProvidedNamespace with // ...

A type provider can provide multiple kinds of types, but for this example I’m going to assume that the provider only does Vector types. This keeps my implementation simple because I don’t need to keep dispatching on ‘what kind of type is the user creating.’ This makes it pretty easy to implement IProvidedNamespace:

// Cheating for simplicity
type Vector() = inherit obj()
 
[<TypeProvider>]
type VectorProvider() =
  interface IProvidedNamespace with
    member this.ResolveTypeName(typeName) = typeof<Vector>
    member this.NamespaceName with get() = "Mindscape.Vectorama"
    member this.GetNestedNamespaces() = [| |]
    member this.GetTypes() = [| typeof<Vector> |]

What’s that do-nothing Vector type for? Well, when the user of the type provider writes Vector<…>, F# wants to interpret “Vector” as a type name. The real type providers included with F# 3.0 create synthetic types to carry the desired provider names, but I’m too lazy to do that, so I’ve just created a dummy type to carry the name “Vector” for me.

For a simple demo, much of the ITypeProvider implementation can also be kept trivial:

[<TypeProvider>]
type VectorProvider() =
  let invalidation = new Event<EventHandler, EventArgs>()
  interface ITypeProvider with
    member this.GetNamespaces() = [| this |]
    member this.Dispose() = ()
    [<CLIEvent>]
    member this.Invalidate = invalidation.Publish

The meat of the type provider is in the remaining ITypeProvider methods: GetStaticParameters, ApplyStaticArguments and GetInvokerExpression.

What can the user specify about the type?

GetStaticParameters specifies what parameters the user can pass to the type provider when they create a type. In our case, we want the user to be able to pass the names of the axes of their vector type — that is, the parameters are an arbitrary number of strings. However, GetStaticParameters doesn’t have a way to indicate “any number of parameters,” so we have to settle for, for example, “you can pass 7 parameters, but they’re all optional.” (In reality you’d make the first one mandatory, but I want to keep things simple.) If we later need to support 8-dimensional vectors, we can simply update the limit in the type provider. The parameters are going to become property names, so they need to be strings. We’ll create a helper method to produce ParameterInfo objects with the right name, data type and optionality.

module Helpers =
  let stringParameter index defaultVal =
    { new ParameterInfo() with
      override this.Name with get() = sprintf "axis%d" index
      override this.ParameterType with get() = typeof<string>
      override this.Position with get() = 0
      override this.RawDefaultValue with get() = defaultVal
      override this.DefaultValue with get() = defaultVal
      override this.Attributes with get() = ParameterAttributes.Optional
    }
 
open Helpers

and then use this to specify what parameters the user can provide to the Vector type provider:

member this.GetStaticParameters(typeWithoutArguments) =
  [1..7] |> List.map (fun i -> stringParameter i "")
         |> List.toArray

This is enough to enable the user of our library to type Vector<"X", "Y"> with intellisense on the parameters. Now we need to actually create a type to realise the user’s specification.

Building the concrete type

Building the type from the parameters provided by the user is the job of the ApplyStaticArguments method. For the Vector demo, I’ll just create a class with properties named for each of the user parameters, and a DotProduct method. (A better provider would create an immutable value type, but I want to keep it simple.)

At the moment, it seems that F# requires ApplyStaticArguments to create a physical assembly on disk. If you build the type in memory, you get strange path errors. I’m not sure if there’s a way around this, but for now I’ll just live with it and litter my temp directory with temporary assemblies.

So the code generator for vector types looks something like this:

module Helpers =
  let makeClass body name =
    let code = "namespace Mindscape.Vectorama { public class " + name + " {" + Environment.NewLine + body + Environment.NewLine + "} }"
    let dllFile = System.IO.Path.GetTempFileName()
    let csc = new Microsoft.CSharp.CSharpCodeProvider()
    let parameters = new System.CodeDom.Compiler.CompilerParameters()
    parameters.OutputAssembly <- dllFile
    parameters.CompilerOptions <- "/t:library"
    // Ignoring error checking
    let compilerResults = csc.CompileAssemblyFromSource(parameters, [| code |])
    let asm = compilerResults.CompiledAssembly
    asm.GetType("Mindscape.Vectorama." + name)
  let makeVector name argnames =
    let propNames = argnames |> Seq.filter (fun arg -> arg <> null && not (String.IsNullOrWhiteSpace(arg.ToString())))
                             |> Seq.map (fun arg -> arg.ToString())
                             |> Seq.toList
    let props = propNames |> List.map (fun arg -> "public double " + arg + " { get; set; }")
                          |> String.concat Environment.NewLine
    let dotProductBody = propNames |> List.map (fun arg -> sprintf "this.%s * other.%s" arg arg)
                                   |> String.concat " + "
    let dotProduct = sprintf "public double DotProduct(%s other) { return %s; }" name dotProductBody
    let body = props + Environment.NewLine + dotProduct
    makeClass body name

This isn’t as intimidating as it looks! The makeClass function wraps a code string in a namespace and class declaration, compiles it and returns the compiled type. The makeVector function removes empty parameters (remember we had to permit lots of parameters but defaulted unused ones to be blank), then spits out a property for each surviving parameter, and a DotProduct method generated by iterating over the parameters.

It turns out that makeVector is pretty much all we need to implement ApplyStaticArguments. The F# compiler tells us the name of the type the user wants us to provide, and the list of parameters supplied by the user, and all we need to do is pass them on to makeVector:

member this.ApplyStaticArguments(typeWithoutArguments, typeNameWithArguments, staticArguments) =
  makeVector typeNameWithArguments staticArguments

Compiling property and method calls to the created type

We are nearly there! Our type provider now provides types to the user on demand, but the user will still get errors if they try to instantiate or invoke those types. GetInvokerExpression is the final piece of the jigsaw, the piece which tells the F# compiler how to generate code for method invocations on the generated type. It’s not yet clear to me how comprehensive GetInvokerExpression has to be, but for the simple Vector example, we just need to handle a couple of cases — construction and method invocation:

member this.GetInvokerExpression(syntheticMethodBase, parameters) =
  match syntheticMethodBase with
  | :? ConstructorInfo as ctor -> Expression.New(ctor) :> Expression
  | :? MethodInfo as mi -> let args = parameters |> Seq.skip 1 |> Seq.cast<Expression>
                           Expression.Call(parameters.[0], mi, args) :> Expression
  | _ -> let pnames = parameters |> Seq.map (fun p -> p.Name) |> String.concat ", "
         failwith (sprintf "ERROR: Don't know what to do in GetInvokerExpression - %s(%s)" syntheticMethodBase.Name pnames)

The most alarming bit about this code is probably the strange F# type operators. We’re just seeing whether F# wants to compile a constructor or a method call, packaging up the appropriate expression tree, then upcasting to the Expression base type to stop F# whining about type mismatches.

And we’re done!

Well, okay, there’s a lot of tidying up to do. But hopefully the samples promised by the F# team will help with that. And at any rate we now have a Vector library that users can use to define Vector types of arbitrary complexity (well, up to 7 dimensions anyway) with a single line of code:

[<Generate>]
type Vector3D = Vector<"X", "Y", "Z">
 
let v3 = Vector3D()
v3.X <- 1.0
v3.Y <- 2.0
v3.Z <- 3.0

(If you count two lines of code here, well, fair enough, but the GenerateAttribute will be removed before the final release.)

As if by magic…

Obviously, the Vector example is pretty trivial, and for most applications it would be easier to write the boring Vector code longhand rather than writing a whole type provider. But the possibilities for this seem endless. Type providers don’t just have to be about data access. In the same way as dynamic programming already enables users to create their own APIs without having to write their own implementations, type providers allow users to create their own APIs without having to write their own implementations, but this time with all the benefits of type checking, intellisense and so on. And of course type providers can be as sophisticated as you like, far more sophisticated than my simple example.

Oh, and one more thing. Although only the F# compiler can invoke type providers, the types generated by the provider are real, compiled-in types. That means you can use those types from C# or Visual Basic code just by referencing the F# project that declares them.

Yep, this is going to be pretty cool.

Watch the video online – be sure to rate it highly!

What more could you want on a Friday afternoon? I mean, maybe a beer but…

Question: Do you enjoy learning about F#? Would you be interested in an instructional series on how to work better with it? Drop us a comment if you’d be interested!

One unusual aspect of the development of Web Workbench is the number of languages we used to develop it. Like most .NET projects, it contains a fair chunk of C#. But quite a bit of the core is written in F#, and it also invokes a large amount of external Ruby and JavaScript code. While using all these languages definitely made it far easier to develop the product, it did also throw up a few challenges and surprises.

How Web Workbench fits together

Web Workbench consists of three major chunks: the language parsers, which work out the information needed for syntax highlighting, intellisense and so on; the third-party compilers, which generate the output CSS and JavaScript files; and the Visual Studio integration, which surfaces these capabilities in the Visual Studio UI.

We chose C# to implement the Visual Studio integration, mainly because the tooling for developing Visual Studio components is C#/VB-centric, and there weren’t any compelling reasons to use anything else. So the rest of this review is from the point of view of integrating non-C# components into a C# framework.

F#

F# is a functional language modelled on OCaml. After shipping from Microsoft Research for several years, it is now included in Visual Studio 2010 out of the box. We used F# to implement the parser components of Web Workbench.

We chose F# for a couple of reasons. The first was that constructs like discriminated unions, records and pattern matching would reduce the amount of boring boilerplate code we had to write. In particular, they provide a great way to quickly represent and traverse an abstract syntax tree (AST). The second was the availability of parser libraries. For a previous project we used fslex and fsyacc, external parser generation tools which come with the F# PowerPack. For Web Workbench we switched over to Stephan Tolksdorf’s beautiful parser combinator libary, FParsec. FParsec made it easy to build up higher-level constructs such as “pair” or “with position” and to parameterise parsers for example to reflect the different prefixes for variables in Sass and Less. It’s probably a subject for a separate blog post, but FParsec alone is a compelling reason to use F# for this kind of project!

Interoperating F# with C# is mostly pretty easy. F# assemblies are normal .NET assemblies and expose classes and functions in the standard way. However, there are a few wrinkles and inconveniences.

Discriminated union members

Suppose you define a discriminated union in F# along the lines of:

type AstNode =
| SelectorNode of string * AstNode list
| ErrorNode of string
| OtherNode

In C#, you’ll see an AstNode base class, with derived nested classes named SelectorNode and ErrorNode, and a property named OtherNode. ErrorNode has a single property named Item, and SelectorNode has properties named Item1 and Item2.

public class AstNode
{
  public class SelectorNode
  {
    public string Item1 { get; }
    public FSharpList<AstNode> Item2 { get; }
  }
  public class ErrorNode
  {
    public string Item { get; }
  }
  public AstNode OtherNode { get; }
}

If you find yourself working with these classes from C#, the names are pretty unmemorable and you need to be careful about maintenance as you add or remove members. It’s therefore worth thinking carefully about how to partition work between the two languages. Ideally you want C# to be able to treat the F# classes as opaque objects, so that whenever it needs to do anything with them, it hands them back to F#.

This isn’t always practical, though. In particular, when unit testing the parser, we wanted to be able to make assertions about the AST that results from a given input. We could have written the tests in F#, but the tooling for unit testing is much better in C#. So instead we wrote a bunch of extension methods for the various AST node types that mapped directly onto the Item members, and this seemed to work pretty well.

This was only for tests, and our production code managed to almost entirely avoid peeking into the structure of AST nodes, by dint of writing most node processing code in F#.

F# and C# functions

One issue that this raised was passing C# functions into F#. For example, our AST traversal code, which needed to understand the structure of AST node types, was written in F#, but one of its arguments was a visitor function, and sometimes we needed that visitor function to be written in C# because it was part of the Visual Studio integration framework. Unfortunately, C# passes function arguments as delegates, whereas F# expects function arguments to be of F# function types. (Internally, F# doesn’t represent function types as delegates — it has its own function type named FSharpFunc.)

To get around this, we created a C#-friendly version of the traversal function, which took a delegate, created a F# lambda to call that delegate, and passed that F# lambda to the real traversal function. Another handy tool is the FSharpFunc.FromConverter function, which is a built-in way to convert a delegate to a F# function.

Options and lists

I generally refer to the F# option type as “nullable types done right” — safer and more self-documenting than null references or nullable value types. Using a F# option from C# is pretty easy, but building them is rather ugly. In the few cases where one of our integration points took an option, we implemented a builder functions in F# to avoid having to write out direct invocations to the FSharpOption type.

The experience with F# lists was pretty similar. Throwing a ToList() at a FSharpList quickly got rid of the F#-ness when we were consuming them, but building them is something you just don’t want to do in C#.

Dependencies

One small but annoying surprise we got when we shipped Web Workbench was that, by default, the FSharp.Core runtime doesn’t get copied locally — but that the Visual Studio installer skips the F# redistributables if the user chooses not to install F#. This led to some hard-to-reproduce errors. So set FSharp.Core to copy local, or use the compiler “standalone” flag, even for VSIX projects.

Ruby

The Sass compiler is built in Ruby, and naturally we wanted to use it as it stood rather than rewriting it. In fact, we originally planned to use the Ruby compiler to do our parsing, but we found it was not fast enough to keep up with users typing, and it stopped after the first error, whereas we need to recover in order to provide syntax highlighting on the rest of the document even after an error. (Especially since the document would spend a lot of its time in error while the user was in the middle of typing something!) So we dropped back to implementing our own parser for real-time aspects such as highlighting and intellisense, but still wanted to use the real compiler to ensure full fidelity — and to save ourselves a lot of effort!

Deployment

To avoid requiring our users to install Ruby and Sass, we decided to use IronRuby, Microsoft’s implementation of Ruby on .NET, to run the compiler. This allowed us to xcopy deploy IronRuby as part of the Web Workbench VSIX, obviating the need for a separate install (and coincidentally ensuring we controlled which version of IronRuby we ran under!).

However, IronRuby depends at runtime a bunch of Ruby library source files. Similarly, Sass ships as a whole tree of Ruby source files. We needed to ensure that all these files were available at runtime, and xcopy assembly deployment wasn’t going to handle that for us. We could have included these source files in the VSIX directly, but this would have been very heavy maintenance because of the number of files. Our solution was to create zip files of the IronRuby and Sass trees, and unzip these at runtime. This incurs a small overhead the first time the compiler runs, but in practice this isn’t significant.

One small but crucial detail is that since IronRuby is being hosted as a DLL rather than running from the command line, it needs to be told where to find the unzipped runtime files. This involves a call to ScriptEngine.SetSearchPaths.

Strings

The .NET Dynamic Language Runtime generally tries to map common CLR types such as integers and strings to the corresponding types in the language at hand. For the most part, this works pretty transparently, but sometimes the mismatch can throw up some odd errors. For example, when we set the Sass :load_paths option so that it could resolve @imported files, we started seeing weird “wrong number of arguments (2 for 1)” errors from the Sass compiler.

In IronRuby, strings should be represented as the built-in MutableString type. However, when using APIs such as ScriptScope.SetVariable, it’s possible to pass a .NET string. IronRuby won’t complain about this, and most of the time it will work. We’re not sure exactly what went wrong on the Sass :load_paths case, but we suspect it may have passed an is_a? String test despite not being a true mutable Ruby string. So the lesson is always to wrap strings using MutableString.CreateAscii before passing them to SetVariable.

A similar issue applies to strings returned from Ruby scripts. You can’t cast them to .NET strings, because they are instances of MutableString rather than String. Use ToString() instead.

Ruby versioning and compatibility

IronRuby 1.1.1 implements Ruby 1.9. However, although the implementation is ‘complete enough for Rails,’ it’s not 100% complete. We got a nasty surprise when the Sass compiler started raising missing method exceptions. There’s a place in Sass where it calls the chr function. Under 1.8 it calls this on a Fixnum, but when it thinks it’s running under 1.9, it calls it on a String. And IronRuby 1.1.1 doesn’t implement String.chr.

We were able to solve this problem fairly quickly once we’d identified it, by running some Ruby code during initialisation to re-open the String class and add the missing chr method. The lesson is more to be aware that third-party implementations of Ruby may not be 100% compatible — and again to carefully read exception messages!

(In most cases, Sass does detect IronRuby and falls back to 1.8 behaviour — this just seems to be a case that slipped through the net, but I thought I’d mention it because other Ruby libraries may not be aware of IronRuby’s quirks the way Sass is.)

Exceptions

Talking of exceptions, we struggled for a while to get meaningful error information out of Sass syntax error exceptions. This wasn’t because Sass didn’t provide the information, it was just that IronRuby didn’t make it easy to find. There are a couple of tricks to be aware of here.

First, the Ruby exception data isn’t presented as a nice simple property on the exception object. Instead, you need to call a static method on RubyExceptionData.

RubyExceptionData rubyException = RubyExceptionData.GetInstance(ex);

Once you have a RubyExceptionData object, you can get the Ruby backtrace, which is invaluable for diagnostics!

Second, when Sass sets exception attributes such as the line number in the SCSS source file, these are available as dynamic properties, but it’s not always obvious what dynamic property you need. I found the following snippet useful for listing the members available on an IronRuby exception that had propagated up into C#:

((System.Dynamic.IDynamicMetaObjectProvider)ex).GetMetaObject(System.Linq.Expressions.Expression.Constant(ex)).GetDynamicMemberNames()

(The fully qualified type names are so that you can paste it into the Visual Studio Immediate window while debugging.) Armed with the list of Ruby members it was usually easy to figure out the dynamic call I needed:

object scssLine = ((dynamic)ex).sass_line();

JavaScript

In the same way as we run the real Ruby Sass compiler on our SCSS files, we run the real JavaScript CoffeeScript compiler on our CoffeeScript files. We looked at three options for this: running on Node.js under Cygwin, running on the DLR using IronJS, and running on a ground-up implementation using Jurassic. The Node approach turned out awfully kludgy, involving as it did launching a separate process through an exciting collection of command scripts, so as with Ruby we turned to the DLR. Unfortunately, IronJS wasn’t able to run the CoffeeScript compiler (though the team are looking at the issue and I believe they now have a fix), so Jurassic it was. Jurassic uses a lot of the same terminology as the DLR so it’s a familiar programming experience, but it doesn’t actually use the DLR under the covers so you can’t use DLR tricks like C# dynamic and IDynamicMetaObjectProvider against it.

Still, running the compiler under Jurassic worked nicely. The CoffeeScript compiler is available as a standalone JavaScript file: we could just load that in from a file or string resource and we were good to go. However, as we had initially planned with Sass, we also wanted to use the CoffeeScript parser rather than writing our own, and that turned out to be a bit more challenging, as we could no longer use the standalone compiler — and the ‘non-standalone’ version worked only on Node.

Running Node modules under Jurassic

The solution we adopted was to implement enough of the Node environment to make the CoffeeScript parser happy. Fortunately, there wasn’t very much of this: in fact, it turned out all we needed to do was implement the require function, which the CoffeeScript parser uses to read in the other files it depends on such as the lexer.

This was reasonably easy to do using Jurassic’s ScriptEngine.SetGlobalFunction method. This allowed us to implement file content resolution in C# or F#, where we had access to the System.IO and System.Resources APIs, and assign that resolution function to the name ‘require.’ Then JavaScript calls to require would end up getting handled by the host function, which loaded the content of the ‘required’ file, passed it back to Jurassic to be executed and captured the results to be returned to the requirer.

The technique of mapping Node externals to host functions should allow arbitrary Node modules to be run under Jurassic, though it could require a fair bit of work if the module has a lot of Node-specific dependencies!

Strings

Similar to Ruby, strings returned from JavaScript aren’t always .NET System.Strings. (Sometimes they are, sometimes they aren’t. It depends on how they were constructed inside the JavaScript code.) Again, use ToString() rather than trying to cast to string.

Strange things in close up

JavaScript is famed for its quirks and pitfalls, and Jurassic makes it easy to enjoy them in the usually drearily regular setting of the CLR. For example, would you guess that these do the same thing?

engine.Execute("a = { }");
engine.SetGlobalValue("a", engine.Evaluate("{ }"));

Of course they don’t. The first sets a to an empty object, as you would expect. The second sets a to undefined. So when injecting code into Jurassic from the host, watch out for JavaScript evaluation quirks!

Conclusion

The polyglot approach is tremendously powerful, but inevitably the integration isn’t completely seamless. That’s probably unrealistic: different languages have different conceptual models, and different semantics even for supposedly common types such as strings.

I’m conscious that this article has focused on the difficulties and surprises, and I want to re-emphasise that the polyglot approach was definitely a net win for us. We simply could not have delivered Web Workbench as a monolingual program. The parsers that underlie the syntax highlighting and intellisense would have been much harder to develop, even with the help of a C#-friendly toolkit like ANTLR, and we couldn’t even have attempted the compilers. I guess we could have shelled out to Ruby and Node but the deployment issues would have been horrible, and of course that’s really just concealing the polyglot nature rather than getting rid of it.

The boundaries between the C# and the Ruby/JavaScript code were pretty well defined and well bounded. Integrating our own F# code into C# was a more interesting design exercise: as I mentioned, some idioms don’t translate well, so identifying the right boundary between the two languages is very important to keeping each side idiomatic and avoiding warts like delegates in F# and ItemX calls in C#. We end up shuttling things back and forth across the language boundary quite a lot in order to do the right processing in the right place, but the experience is generally pretty seamless.

Based on our experience with Web Workbench, polyglot programming isn’t something you should do lightly. If you’ve only got one or two files that would be better off as F# or Ruby or JavaScript, then it’s probably more efficient to port them to your language of choice than to deal with the integration and deployment issues. But it’s nothing to be afraid of, either. In this post I’ve tried to alert you to some of the things you’ll encounter and how we solved them, but I’ve also tried to emphasise that the difficulties were outweighed by the benefits. We hope this will encourage you to keep your eyes open for places where polyglot programming can help you too!

If you enjoyed this article, please consider voting for it on Hacker News — thanks!

internal class WindowsIdentityAuditInfoStrategy : IAuditInfoStrategy
{
  public static readonly IAuditInfoStrategy Instance = new WindowsIdentityAuditInfoStrategy();
  private WindowsIdentityAuditInfoStrategy() { }
  public AuditInfoMode Mode { get { return AuditInfoMode.WindowsIdentity; } }
  public string GetCurrentUser() { /* super-secret Mindscape proprietary code */ }
}

The annoying thing about this is that I don’t really need all the overhead of a class, and could also do without the trickery required to make it a singleton. What I’d really like to do is declare an object that implements the interface. That would save me writing all the class verbiage, and also make it clearer to readers of my code that the object was a singleton.

If I’d been using F#, I could have done exactly this. F# has a feature called object expressions, which basically allow you to create an object with members and behaviour, without creating a class to contain those members and behaviour. Let’s look at an example.

let windowsIdentityAuditInfoStrategy = {
  new IAuditInfoStrategy with
    member this.Mode = AuditInfoMode.WindowsIdentity
    member this.GetCurrentUser() = WindowsIdentity.GetCurrent().Name }  // oh no!  I gave it away!
 
printfn "%A" (windowsIdentityAuditInfoStrategy.GetCurrentUser())
// prints "athena\Ivan"

What’s going on here? That opening brace followed by new IAuditInfoStrategy tells F# that this is an object expression: that I want an object that implements IAuditInfoStrategy as shown. F# obligingly creates a suitable object by some nefarious means which I don’t have to worry about, and returns it into my variable.

Object expressions aren’t limited to interfaces. You can use them whenever you want to inject a bit of implementation without creating a whole new type:

let purportedDromedary = {
  new Object() with
    member this.ToString() = "I'm a dromedary" }
 
printfn "%A" purportedDromedary
// prints I'm a dromedary

Nor are they limited to singletons. In fact a handy feature of F# object expressions is that they can capture local variables, just like closures do:

let purported thingy = { new Object() with member this.ToString() = "I'm a " + thingy }
 
printfn "%A" (purported "wildebeeste")
// prints I'm a wildebeeste
printfn "%A" (purported "trask")
// prints I'm a trask

Obviously impersonating equatorial wildlife is fairly specialised as business requirements go, so let’s go back to the auditing example. In LightSpeed, the IAuditInfoStrategy is public, so that customers can implement their own application-specific user identification strategies. Perhaps the application has its own custom security system. Perhaps it is integrated into Lotus Notes– but no, some things are too horrible to contemplate. Regardless, we might find it useful to define a common base class for custom strategies:

[<AbstractClass>]
type CustomAuditInfoStrategy() =
  interface IAuditInfoStrategy with
    member this.Mode = AuditInfoMode.Custom
    member this.GetCurrentUser() = this.GetCurrentUserCore()
  abstract member GetCurrentUserCore : unit -> string

So far, this is just a normal F# abstract class, to save us having to reimplement Mode every time. Let’s put it to the all-important work of making someone else carry the can:

let blame x = {
  new CustomAuditInfoStrategy() with
    member this.GetCurrentUserCore() = x }

What does the blame function do? It creates a new CustomAuditInfoStrategy whose GetCurrentUserCore method always returns our designated scapegoat. Notice that we haven’t had to create a ScapegoatingStrategy class to contain this brutal but realistic business logic: we can do it inline in the blame function. This keeps the blaming logic within the blame function instead of spinning it out to a separate location. And of course we can call the function multiple times to shift the blame around as required. Let’s try it out:

let context = new LightSpeedContext()
context.AuditInfoMode <- AuditInfoMode.Custom
 
context.CustomAuditInfoStrategy <- blame "bob"
printfn "%A" (context.CustomAuditInfoStrategy.GetCurrentUser())
// prints "bob"
 
context.CustomAuditInfoStrategy <- blame "kate"
printfn "%A" (context.CustomAuditInfoStrategy.GetCurrentUser())
// prints "kate"

Of course, under the surface, the F# compiler is defining derived classes of CustomAuditInfoStrategy just as you would if you were implementing this in C#. (Load the compiled F# code into a C# decompiler such as Reflector if you want to see what’s really going on.) But at the source code level, you don’t need to worry about this: you can just spin up objects to implement interfaces or abstract classes, or just to tweak concrete classes, and save yourself the overhead of writing a special class definition out longhand.

public static IEnumerable<string> FilesBelow(string directory)
{
  foreach (var file in Directory.EnumerateFiles(directory))
  {
    yield return file;
  }
  foreach (var subdir in Directory.EnumerateDirectories(directory))
  {
    // yield return FilesBelow(subdir);  // won't compile
    foreach (var file in FilesBelow(subdir))
    {
      yield return file;
    }
  }
}

Note the extra foreach loop over the results of the recursive call.

F# has something similar to iterators, which it calls sequence expressions. A sequence expression is introduced by the term seq, and similar to C# it uses the term yield to produce values:

seq { for n in 1 .. 10 do yield n * n }  // yields 1, 4, 9 ... 81, 100

(You can use -> as a shorthand for do yield here, but I’ve spelled it out explicitly because of what’s coming next.)

Like a C# iterator, a F# sequence expression can call functions which return sequences and yield up the results. We can therefore rewrite our C# directory flattening function like this:

let rec filesBelow directory =
  seq {
    for f in Directory.EnumerateFiles(directory) do yield f
    for d in Directory.EnumerateDirectories(directory) do
      for f in (filesBelow d) do
        yield f
  }

Unlike C#, however, F# sequence expressions do have a special keyword for yielding an entire sequence. That keyword is yield!, pronounced yield-bang. yield! allows us to tighten up our recursive iterator nicely:

let rec filesBelow directory =
  seq {
    for f in Directory.EnumerateFiles(directory) do yield f
    for d in Directory.EnumerateDirectories(directory) do yield! (filesBelow d)
  }

Using yield! on the results of the recursive call allows us to avoid the noise of the extra ‘for’ expression.

> let l = [ 1; 2; 3 ];;
val l : int list = [1; 2; 3]
> l.Length;;
val it : int = 3
> List.length l;;
val it : int = 3

Several other List module functions, such as head and tail, are also duplicated by properties. It’s not just lists, either: for example, the .NET String.Length property is duplicated by the F# library String.length module function.

So when would you choose a member such as .Length member over a function such as List.length or String.length, or vice versa?

The answer, perhaps surprisingly, is that you should usually choose the function. The reason is to do with F# type inference.

In F# code, you don’t usually need to specify the types of variables and parameters, because the compiler will work them out by analysing the code. Take a look at the following code fragment:

let twiceLength a = 2 * List.length a

F# infers that twiceLength takes a list and returns an int. We’ve not had to specify this: F# has worked it out. How?

Well, when F# tries to work out the type of a, it looks at how a is used in the body of the function. It sees that a is passed to the List.length function. Now it looks at the List.length function and sees that its argument is of list type. So, F# reasons, a must be of list type. Job done!

But what if we wrote the function using a member?

let twiceLength a = 2 * a.Length

Oh no! We get a compiler error, “Lookup on object of indeterminate type based on information prior to this program point.” What does this mean? It means that F# can only figure out that a must be something with a .Length member. And that’s not enough to pin down the type. List has a .Length member, String has a .Length member, ExperimentalGermanFilm has a .Length member… F# can’t tell which of these is intended, so automatic type inference fails, and we have to go back to writing it out longhand:

let twiceLength (a : String) = 2 * a.Length  // Now F# can resolve the .Length call

In terms of the amount of code, there isn’t much to choose between the two. And of course, if you’re working with a type that only comes with members, not helper functions, then you’ll have to go the type annotation route — not that there’s anything wrong with that. But type inference is a bit more idiomatic where you have a choice.

And that, my liege, is how we know the earth to be banana shaped.

Consider the following line of C#:

var isReticulated = delegate(Spline s) { return s.IsReticulated; };

As the Stack Overflow poster discovered, this doesn’t compile. Why not? Because although the right hand side is clearly a function from Spline to bool, C# doesn’t recognise that as a type. C# only recognises specific delegate types such as Func<Spline, bool>, Predicate<Spline> or Converter<Spline, bool>. So you have to pick one of these and spell it out:

Predicate<Spline> isReticulated = delegate(Spline s) { return s.IsReticulated; };

And woe betide you if you have to deal with APIs that have made different choices, because there’s no conversion between ‘compatible’ delegate types:

public Predicate<Person> GetFilter(FilterSpecification spec) { ... }
 
public IEnumerable<Person> GetFilteredPeople(FilterSpecification spec)
{
  var filter = GetFilter(spec);
  return _people.Where(filter);  // compiler error
}

The Where method demands a Func<T, bool>, so if all you have is a Predicate<T> then you’re stuffed, even though they’re both functions from T to bool! Instead you have to write a guffy little adapter:

return _people.Where(p => filter(p));  // everybody loves code noise

Contrast this with F#, in which functions do have a type:

let isReticulated = fun (s : Spline) -> s.IsReticulated

The compiler figures out the type as Spline -> bool. Which means you can pass this function to anything that expects a function from Spline to bool. You don’t need to worry about the difference between Funcs, Predicates, Converters and goodness knows what else: instead, function types are standardised at the language level.

let reticulatedSplines = List.filter isReticulated splines  // List.filter takes a 'T -> bool
let antifilter predicate list = List.filter (predicate >> not) list  // Compiler infers type of predicate as 'T -> bool
let unreticulatedSplines = antifilter isReticulated splines  // so isReticulated is compatible with antifilter

Any function with a function argument can work with any function with the right signature — not just ones that happen to have been packaged up into the right delegate type.

And that, at bottom, is why functions are first class in F#, and not in C# or Visual Basic.