F# computation expressions for beginners, part 1: what’s the problem?

One of F#’s most intriguing and baffling features is computation expressions, also known as workflows.  Computation expressions are intriguing because they override the normal F# control flow, allowing user code to decide when and if to proceed to the next step.  And they’re baffling for a number of reasons, but the first is probably, ‘why the heck would I want to override the normal F# control flow?’

To answer that, let’s look at a couple of examples.

Null-safe member calls

If I had a dollar for every time someone asked for a null-safe member operator in C#, I’d have $18.50.  The idea is that if I should be able to write a long chain of member calls in C#, but if one of the intermediate calls returns null then the whole expression would be null instead of throwing an exception.

    string ppname = p.Partner.Puppy.Name;
    // but what if p or p.Partner or p.Partner.Puppy is null?

A few people have suggested that a new operator, typically written .? or ?., be added to C# to handle this situation.

    string ppname = p.?Partner.?Puppy?.Name;

And maybe these people will get lucky in 2015 or whenever, but what if you need to write some code before 2015?  You have to do a bunch of explicit control flow:

    string ppname = null;
    if (p != null)
    {
      if (p.Partner != null)
      {
        if (p.Partner.Puppy != null)
        {
          ppname = p.Partner.Puppy.Name;
        }
      }
    } 

This works fine, but (a) is boring to write and (b) obscures the core logic (the partner’s puppy’s name) in the mess of if statements.

Asynchronous programming

How do you access a remote or slow resource in C# or Visual Basic, without blocking?  Through the joy of callbacks, of course.

    private static void GetWebStuff1()
    {
      WebClient client = new WebClient();
      client.DownloadStringCompleted += OnDownloadStringCompleted;
      client.DownloadStringAsync(new Uri("http://www.google.co.nz/"));
    }
 
    private static void OnDownloadStringCompleted(object sender,
      DownloadStringCompletedEventArgs e)
    {
      Console.WriteLine(e.Result);
    }

As has been observed by everyone and his dog, the problem with this is that it splits the logical flow (download this page and write it to the console) across multiple methods, making it hard to understand and reason about.

As with the null-safe chain, it’s possible to address this at the language level, and in fact C# 5.0 will do exactly that via the async and await keywords:

    private static async void GetWebStuff2()
    {
      WebClient client = new WebClient();
      string response = await 
        client.DownloadStringTaskAsync(new Uri("http://www.google.co.nz/"));
      Console.WriteLine(response);
    }

This will be jolly nice when it arrives, but once again, it puts developers at the mercy of the language designers.  Even if the C# team do decide to support your control flow scenario, you’ll probably have to wait a few years before that support arrives.  By which time your project has long since failed and you are living in a shopping trolley and yelling at clouds.

Computation expressions

On the surface, these two examples seem entirely unrelated.  But both of them involve wanting to write code in a simple, linear, top-to-bottom or left-to-right style, but being foiled by the fact that you can’t proceed naively from one statement to the next.  In the first example, we want to proceed to the next member call only if the previous one returned non-null; in the second, we want to proceed to the next statement only when the async statement has finished doing its work.

F# computation expressions are an attempt to handle this at a library level instead of a language level.  Roughly speaking, computation expressions allow you to control if and when – and indeed how – control passes from one statement to the next.  (They actually do more than this, but this will do for now.)

And, unlike C#, you can create your own kinds of computation expression to handle control flow idioms that are particular to your own projects.

Which brings us to the second baffling thing about F# computation expressions, which is that they do my head in.  (Technical term.)  Computation expressions are a bit like LINQ.  They’re dead easy and incredibly convenient to use.  But implementing your own kind of computation expression is a whole other matter.  So that’s what I’ll be trying to get my head around in this series.