Why basic numeracy is important

A quite extraordinary transcript of a billing dispute:

[Caller]: Okay, I think I have to do this again. Do you recognize that there's a difference between one dollar and one cent?
[Agent]: Definitely.
[Caller]: Do you recognize there's a difference between half a dollar and half a cent?
[Agent]: Definitely.
[Caller]: Then, do you therefore recognize there's a difference between .002 dollars and .002 cents?
[Agent]: No.
[Caller]: No?
[Agent]: I mean there's... there's no .002 dollars.

Via.  If a dispute over $71 versus 71c seems beneath your notice, scroll up to the top of the thread where the business and economics editor of a major US magazine gets equally defensive about a similar error, except on the order of trillions of dollars.

Then again, given that the said economics editor is apparently paid $200000 per year despite a history of such errors, maybe the title should be “Why basic numeracy is not important.”

Sunday cats in domestic appliances blogging

When a mouse escapes into an unfeasibly small space such as the toe of a slipper, some cats wait patiently it to emerge.  Others, more determined, attempt pursuit.

Prodnose.  Surely a slipper is not a domestic appliance within the meaning of the act?

Myself.  Nor, oaf, is it Sunday.

Decommoditise me, baby

Bruce Schneier: “This is important because it destroys what’s left of the normal business rela­tionship between IT companies and their users. We’re not Google’s customers; we’re Google’s product that they sell to their customers.”  Though this isn’t new: free-to-air television (with  few notable exceptions such as the BBC) has always worked this way.

F# computation expressions for beginners, part 2: keeping it simple

When I started trying to get my head around F# computation expressions, I went looking for nice simple, basic examples.  Unfortunately, even the simplest examples I could find were rather intimidating.  Here’s my attempt to strip it back to the very basics.

Use case

The example I’m going to use is based on the null-safe member example from the previous instalment.  However, F# tends to eschew both nulls and members in favour of options and functions, so instead of dealing with members that might be null, I’m going to deal with functions that return options.

So my computation expression will work just like normal F# control flow, except that if a function call returns None instead of Some, I’ll treat that as a failure and bail out on the rest of the expression.

Here’s an example of the kind of function I want to be able to use:

let tryDecr x n = 
  if x > n then Some (x - n) else None

And here’s an example of how I want to be able to use it:

let maybeDecr x = maybe {
    let! y = tryDecr x 10
    let! z = tryDecr y 30
    let! t = tryDecr z 50
    return t
  }

The idea is that if the first tryDecr call fails, the maybe block will stop it going on to the second tryDecr, and so on.  I don’t need to clutter the code up with explicit if expressions or pattern matching: the computation expression will magically abort out of the block (and return None) the first time any function returns None.

let! – all the letting, but with more excitement

Notice that inside the maybe block I’m using let! for assignment instead of the normal let.  This is how my computation expression gets to interfere in the control flow.  The normal let doesn’t give the custom flow logic a chance to get involved.  Inside a computation expression, I have to use let! instead when I want my custom logic to run.  That is, code inside a computation expression block still has to opt into whatever weird behaviour the computation expression defines.

Once we’ve seen how to build a computation expression, it will be clear that there are other reasons we need to keep the standard assignment behaviour around.  I’ll try to come back to this.

A workflow builder for maybe

What is the custom flow logic for maybe expressions?  Informally it looks like this:

If the expression at hand returns None, then the value of the whole computation expression will be None; don’t bother evaluating the rest of the expressions.

If the expression at hand returns Some a, then carry out the rest of the computation expression on the value a.

(That “on the value a” bit in the second paragraph is deliberately nebulous for now.)

We need to tighten up this informal specification into code, but before we can do that we need to know where that code is going to sit.  The answer is in a builder class. The methods you implement on the class depend on what constructs you need in your computation expressions.  For overriding control flow in a let!, we need to implement a method on the builder class called Bind.

The signature of Bind is defined by F# in terms of the kind of data we want to be able to use in let! expressions.  Basically it takes a value representing the result of the expression at hand – the right hand side of the let! – and a function representing the rest of the computation expression, and it has to return a value representing the result of the computation expression as a whole.

Implementing the custom flow logic for maybe

In the maybe example, the right hand side of the let! has to evaluate to an option value.  And the rest of the computation expression is going to operate on the content of that option value, if it has any.  And the result of the maybe block as a whole must be an option, because we have to be able to return None if any of the contained expressions evaluate to None.

So our Bind method has to take an option value and a function from non-option to option, and return an option:

Bind : 'a option -> ('a -> 'b option) -> 'b option

With F# forcing this signature on us, and our informal specification at hand, writing the implementation becomes almost trivial:

type MaybeBuilder() =
  member this.Bind(p, rest) = match p with
                              | None -> None
                              | Some a -> rest a

What is this saying?

If p is None, then Bind doesn’t evaluate the rest function, and returns None.

If p is Some a, then Bind returns the rest function applied to a.

But when F# calls Bind, p is the result of the expression at hand – the right hand side of the let! – and rest is a function comprising the rest of the computation expression, and whatever Bind returns becomes the result of the computation expression as a whole.  Calling rest on a is exactly “carrying out the rest of the computation expression on a.”  So this seems like a pretty exact translation of our informal specification.

Getting a value out of a maybe block

So now we can write a sequence of let! operations, and our Bind implementation will take care of conditionally running the rest of the computation.  But eventually that ‘rest’ is going to have to come up with a value.

Here’s the ‘how to use it’ sample again:

let maybeDecr x = maybe {
    let! y = tryDecr x 10
    let! z = tryDecr y 30
    let! t = tryDecr z 50
    return t
  }

Obviously, we need to implement the return keyword.  To do this, we need to add another method to our builder class, the Return method.

What does Return look like?  Well, at some point we know that Return is going to be the ‘rest of the computation.’  That means it’s got to be compatible with the rest argument to Bind.  Which means Return has to be a function from non-option to option.  If the computation got as far as Return, then it means Bind didn’t abort the computation early, which means the computation was successful and we want to get the value out.  How do we get a value in an option?  Using Some, of course!

So Return pretty much writes itself:

type MaybeBuilder() =
  member this.Return(x) = Some x

A builder object

It turns out that Bind and Return are all we need for a simple conditional chaining strategy.  So all we need to do now is define that ‘maybe’ we’ve been blithely flinging around and hook it up to our builder class.

This turns out to be deceptively easy: just declare maybe to be an instance of the builder class!

let maybe = new MaybeBuilder()

‘maybe’ isn’t a keyword: it’s just a variable.

Putting it all together

Here’s our conditional flow engine in full:

type MaybeBuilder() =
  member this.Return(x) = Some x
  member this.Bind(p, rest) = match p with
                              | None -> None
                              | Some a -> rest a
 
let maybe = new MaybeBuilder()

I’ll add a bit of logging to the tryDecr method so we can see how often it gets called, then use it in a maybe block:

let tryDecr x n = 
  printfn "Conditionally decrementing %A by %A" x n
  if x > n then Some (x - n) else None
 
let maybeDecr x = maybe {
    let! y = tryDecr x 10
    let! z = tryDecr y 30
    let! t = tryDecr z 50
    return t
  }

And let’s see what happens:

> maybeDecr 100;;
Conditionally decrementing 100 by 10
Conditionally decrementing 90 by 30
Conditionally decrementing 60 by 50
val it : int option = Some 10
> maybeDecr 30;;
Conditionally decrementing 30 by 10
Conditionally decrementing 20 by 30
val it : int option = None
> maybeDecr 5;;
Conditionally decrementing 5 by 10
val it : int option = None

In the first test, tryDecr has been successful each time, so normal control flow has been sustained, and maybeDecr has produced the correct result.

In the second and third tests, tryDecr has failed on the second and first attempt respectively (calculating z and y respectively).  But instead of going on to attempt the remaining calculations, the maybe block has returned None immediately – without us having to write explicit code to check for failure.  The block allows us to write top-to-bottom code and let the ‘maybe’ object take care of the more complex flow that is actually required.

Conclusion

The maybe block is about as simple as a computation expression can get.  I’ve tried to strip it back to the absolute basics, so that it’s simple enough for me to get my head around.  Nevertheless, it’s not a toy (although I have illustrated it with a toy example): it does real work which could be used to simplify real code.

With this basic example at hand, we have a foundation for building more sophisticated and useful workflows, and for exploring what’s actually going on when F# encounters a computation expression.

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.

Reactive Extensions - Wellington .NET user group

Thanks to everyone who came along to undergo the "reactive functional brain inversion process."  The dizziness you are now experiencing is normal and should fade over the next eleven to twelve months.  In the meantime, here are the bits.

Introduction to the Reactive Extensions - slides

Reactive Extensions demos

(The zip file of the demos includes the Rx binaries but I've found that you will probably need to either install Rx or fix up the reference paths.  The original copy of the WQL demo, by Bart de Smet, is here.)

The Reactive Extensions home page includes several useful resource links.  I'd particularly draw people's attention to Jeffrey van Gogh's blog which has been working through a detailed example of using Rx for asynchronous file reading, and don't forget to check out Bart de Smet's PDC presentation.