Category Archives: Functional

Asyncing the F# Way

I recently gave a talk at the Winnipeg .Net User Group. This talk was focused on features of F# that are going to make their way into the world of C#. During the presentation I was talking about using local functions to wrap async functions. It was at this point someone asked if F# can do async/await. Well, the answer is yes.

The Async Builder

F# uses an Async Computation Expression for creating asynchronous workflows. The notation we use to denote an async computation is the async { ... }. Anything inside the curly braces are executed within the computation expression.

async {
    printfn "Good night"
    do! Async.Sleep 2000
    printfn "Good morning"
} |> Async.RunSynchronously

Looking at the example above, we have our async { ... } and our code within the curly braces. If you run the code in your REPL (Read Evaluate Print Loop) it will print “Good night”, wait 2 seconds, then print “Good morning”.

The Bang notation

The do! (do-bang) is our way of expressing we are evaluating an asynchronous expression. The do itself indicates we don’t care about the result. It’s the ! (bang) that the AsyncBuilder uses to unwrap the asynchronous expression’s result. It’s syntactic sugar to ensure our code is expressive and readable.

We use let! (let-bang) when we want to use the result of an asynchronous expression. In the doWorkAsync example below, we use the let! to bind the result of addAsync to the label result so we can print it.

let addAsync x y = async { return x + y }

let doWorkAsync = async {
    let! result = addAsync 4 6
    printfn "Result: %d" result

Async.RunSynchronously doWorkAsync

Binding IDisposable

When we have an asynchronous expression which returns an object implementing IDisposable we should bind the result with use!. This unwraps the asynchronous expression, binds the disposable object, and disposes of the object when it falls out of scope. An example of use! is when retrieving the contents asynchronously from a website.

open System.IO
open System.Net

let getUrlContentSizeAsync (url : string) = 
    async {
        let request   = WebRequest.Create (url)
        use! response = request.AsyncGetResponse ()
        use stream    = response.GetResponseStream ()
        use reader    = new StreamReader(stream)
        let contents  = reader.ReadToEnd ()
        return (url,contents.Length)

getUrl "" |> Async.RunSynchronously

In the code above we are using the use! to unwrap the IDisposable response object. This in turn performs an automatic clean up when the object is no longer required.


We write asynchronous code in F# using the AsyncBuilder. The builder itself is syntactic sugar allowing us to write clean and expressive code. We use the Bang notation to unwrap the asynchronous calls within the builder. There are do!, let!, and use! to handle the results of an asynchronous expression. We’ve currently only looked at running the asynchronous code one way using the Async.RunSynchronously. We’ll look at more ways of running our code in a future post.

Deconstructing Records

Deconstruction let us focus on the values we want to match in our patterns. We’ve shown we can deconstruct tuples, but what about records? Absolutely.

A record is a data structure with named values. Records are immutable by default. We use records in exchange of tuples. Records give better context to what data is being represented. We’ll use the Astronaut record defined below as our data representation.

type Astronaut = { Name : string; Year : int }

Suppose we want to print an appropriate message based on the astronaut’s name. We’ll do a simple greeting for all astronauts except for “Dave” and “Neil”. We can create our function with a pattern match as below.

let greeting astronaut = 
    match astronaut with
    | {Name = "Dave"} -> "I'm sorry Dave, I'm afraid I can't do that."
    | {Name = "Neil"} -> "The first person to set foot on the moon."
    | {Name = name}   -> sprintf "Hello %s." name

If you look at the patterns in the match you will note we are deconstructing the Name value from the astronaut argument. Someone reading the code can easily see we are interested in the astronaut’s name.

We could be even more specific with matching on our Astronauts by using patterns below:

let greeting astronaut = 
    match astronaut with 
    | {Name = "Dave"; Year = 2001 } 
         -> "I'm sorry Dave, I'm afraid I can't do that."
    | {Name = "Neil"}               
         -> "The first person to set foot on the moon."
    | {Name = name}                 
         -> sprintf "Hello %s." name

We’ve gone further in isolating the values we want for our patterns. The more values you add the more specific your patterns become. In the example above we have a case using the Name and Year deconstructed from the astronaut to get Hal’s response to Dave. All other astronauts named Dave will get the standard greeting.

Deconstruct OR what…

Let’s go back to matching on name only. What if our name isn’t proper case? What if Dave is actually a “dave” or “DAVE”? We may still want to match on those “Dave”s. Here is where some of the power of F#’s pattern matching starts to shine. We can write our pattern to include those other “Dave”s by combining deconstruction and the OR Pattern.

let greeting astronaut = 
    match astronaut with
    | {Name = "Dave" | "dave" | "DAVE"} 
        -> "I'm sorry Dave, I'm afraid I can't do that."
    | {Name = "Neil"} 
        -> "The first person to set foot on the moon."
    | {Name = name}   
        -> sprintf "Hello %s." name

We’ve certainly improved our pattern to include more cases of “Dave”. We can take our pattern one step further and make our patterns case insensitive. The first way will be more familiar for OOP developers. We can use the property accessor to get the Name to then lower and use the property again to print the name. The other way would be to use a pattern match in the function signature. We can do pattern matching and deconstructing in the function arguments.

let greeting astronaut = 
    match astronaut.Name.ToLower() with
    | "dave" 
        -> "I'm sorry Dave, I'm afraid I can't do that." 
    | "neil" 
        -> "The first person to set foot on the moon."
    | _      
        -> sprintf "Hello %s." astronaut.Name

let greeting' {Name=name} = 
    match name.ToLower() with
    | "dave" 
        -> "I'm sorry Dave, I'm afraid I can't do that."
    | "neil" 
        -> "The first person to set foot on the moon."
    | _      
        -> sprintf "Hello %s." name

It’s not overly common to use deconstruction in the function signature. It can lead to some ambiguity in the code. We are focusing on the values we care about, however the function signature may no longer have the same readability it did before with the astronaut value.


We’ve covered the ability to deconstruct records in our patterns. We aren’t limited to one value for deconstruction. We can match on any number of values in a record, and the number of values can vary between patterns. F# is not limited to only deconstruct records in the match with construct. Matching can be used by the function construct and in the declaration of function arguments. We can also combine deconstruction with OR to reduce the number of patterns and improve readability. It’s the ability to combine patterns which let’s the power of F# shine its expressiveness.

Beyond Constant Pattern Matching

Pattern matching is a vital aspect of functional programming. It can make our code more expressive by eliminating noise. We’ll look into a few more patterns that give us the power and flexibility to create readable match expressions.

OR Pattern

The OR pattern is used to group multiple patterns which return the same result. This can be considered a short hand for multiple patterns. A simple match expression verifying a number is below 10 and prime can be written multiple ways.

// Return value for each number
let isPrimeBelow10 = match number with
                     | 2 -> true
                     | 3 -> true
                     | 5 -> true
                     | 7 -> true
                     | _ -> false

// Using the OR pattern
let isPrimeBelow10 = match number with
                     | 2 | 3 | 5 | 7 -> true
                     | _             -> false

The second version of isPrimeBelow10 is easier to reason about as it declares the patterns 2, 3, 5, and 7 are grouped to the same result. The noise of all the extra -> true has been removed. This gives the reader a visual cue about the relationships of the patterns as well as reduces duplicate code.


Guards are used to match on patterns that require more than a constant. We use the when keyword followed by an expression which evaluates to a boolean. If the guard expression evaluates to true then that pattern matches. Let’s say we want to classify a value as normal if it is within 100 to 200. That would take a lot of patterns if we used the OR pattern exclusively. It also doesn’t solve the situation if we wanted to indicate whether the value was high or low. We can use guards to accomplish our task.

let withinNormals number = match number with
                           | x when x > 200 -> High
                           | x when x < 100 -> Low
                           | _              -> Normal

We have three patterns with two of them using guards. The first pattern binds number to the label x and evaluates x > 200. If it evaluates to true, the match returns High. The second pattern does something similar, with the exception of evaluating x < 100. The final pattern is a wildcard which returns if the previous patterns are not matched.

Guards allow us to do more than just match on constants. We can expand our withinNormals to be more reusable.

let withinNormals (lowLimit, highLimit) number = 
    match number with
    | x when x > highLimit -> High
    | x when x < lowLimit  -> Low
    | _                    -> Normal

We have the same three patterns but this time we are using the arguments passed in determine the lower and upper limit. Guards let us do more than match on constant values, they give us the flexibility to create reusable patterns.


Deconstruction allow the pattern to focus on what is being pattern matched. We left off Pattern Matching with Constants with a pattern matched version of Fizz Buzz. Here is the implementation again.

let printFizzBuzz number = match (number % 3, number % 5) with
                           | (0, 0) -> printfn "FizzBuzz"
                           | (0, _) -> printfn "Fizz"
                           | (_, 0) -> printfn "Buzz"
                           | _      -> printfn "%d" number

The printFizzBuzz function takes a number and creates a tuple of the results of number modulus 3 and 5. Our patterns deconstruct the tuple and match those results with constants.

We can even completely ignore values from deconstructed objects. Here we only care about the third value in the tuple. We are using the patterns to deconstruct the tuple while ignoring the first two values in the tuple. Our patterns are only focused on the values important to it.

match tupleOf3 with
| (_,_,0)            -> "0"
| (_,_,1)            -> "1"
| (_,_,x) when x < 0 -> "Negative"
| _                  -> "Larger than 1"  


The OR pattern can be used to group patterns together which have the same return value. Redundant code can be eliminated with the use of the OR pattern. Guards give match expressions the ability to compare values in patterns and not restrict us to constants. Deconstruction let patterns focus on what is being matched instead of dealing with the whole object.

Pattern Matching with Constants

Pattern matching is a staple of any functional programming language. F# has a decent pattern matching system with 16 matching patterns out of the box. You also have the ability to extend the pattern matches by using Active Patterns. Let’s start with some common pattern matches for F#.

The basic syntax for pattern matching in F# is a match with expression. The with is then followed by a vertical bar and a pattern.

match item_to_be_matched with
| pattern -> result

This is a single case pattern match. It’s not used much at all. Generally pattern matches have multiple cases. Each pattern is separated by a vertical bar. You can think of the vertical bar as being “OR”.

match item_to_be_matched with
| pattern1 -> result1
| pattern2 -> result2
| patternN -> resultN

Constant Pattern

Using a constant pattern is very similar to a switch statement in C#. Any type that can be defined as a constant can be used in this type of pattern.

match number with
| 0 -> "Zero"
| 1 -> "One"
| 2 -> "Two"
match role with
| "administrator" -> Administrators
| "manger"        -> Managers
| "user"          -> Users

Exhaustive vs Incomplete Patterns

A pattern match is considered exhaustive when it accounts for every possible pattern. We don’t always have to use exhaustive patterns, however we do run the risk of receiving an exception if no match is found. If you are using an editor like Visual Studio or Visual Studio Code (with Ionide-Fsharp) you will get highlighting indicating a pattern may not be accounting for every possibility. It’s preferable to use exhaustive patterns to eliminate the possibility of a match failure exception.

Visual Studio Code with Ionide-Fsharp indicating an incomplete pattern.
VSCode with Ionide-FSharp - Incomplete Match

Wildcard Pattern

The wildcard pattern is used as a catch all pattern. This is denoted by an underscore or a generic label in the pattern. Use of an underscore informs the next developer the value is of no importance. The wildcard pattern is very much like the default clause of a switch statement in C#. This will take any incomplete pattern and make it exhaustive. We can make the isZero function exhaustive by adding the wildcard pattern.

let isZero number = match number with
                    | 0 -> true
                    | _ -> false
let greeting name = match name with
                    | "hal" -> printfn "I'm afraid I can't do that Dave"
                    | _     -> printfn "Hello %s" name

You do have to be careful when using the wildcard. If a business requirement changes and you forget to add the new pattern, the wildcard will happily swallow the match thus leaving you with some unintended results.


Pattern matching with constants is very similar to the C# switch construct. This is where the similarities end until C# 7. As I mentioned at the beginning of this post, F# has 16 different patterns. We’ll be getting into more of those patterns in future posts. Here is a FizzBuzz implementation using the constant pattern match with Tuple deconstruction. Exciting things are on the way.

let printFizzBuzz number = match (number % 3, number % 5) with
                           | (0, 0) -> printfn "FizzBuzz"
                           | (0, _) -> printfn "Fizz"
                           | (_, 0) -> printfn "Buzz"
                           | _      -> printfn "%d" number

Currying and Applying Arguments

I gave a talk called Some(‘F#’) is Better Than None at Winnipeg Code Camp on January 28, 2017. The talk was catered toward developers who have never looked at F# or those who never considered F# as being a useful prototyping tool.

During the talk I made a brief mention to currying and partial application. After the talk I received a great question along the lines of: if every function only takes one argument, how is it we are able to pass multiple arguments to a function?


Currying is the process of transforming a function which takes multiple arguments into a sequence of functions where each new function takes only one argument. If we were to write the function:

let addThreeNumbers x y z = x + y + z

This function looks like it takes three arguments, however the signature of addThreeNumbers is converted to int -> int -> int -> int. We can read the function signature as: addThreeNumbers has type of int goes to int goes to int goes to int. The last type in the signature denotes the return type of the function.

Applying arguments

Using the addThreeNumbers function we defined earlier, we can call the function as:

addThreeNumbers 1 2 3

Since we are passing in the full number of arguments the function evaluates immediately giving us the result of 6.

As we are passing in arguments, the function applies what it can with the arguments given. Each time we add an argument it peels off the leading type ->, eventually reaching the point where there is nothing left to apply which then evaluates the result.

// int -> int -> int -> int
let addThreeNumbers x y z = x + y + z

let result = addThreeNumbers 1 2 3
// can be thought of as
let result' = (((addThreeNumbers 1) 2) 3)

// You can also apply the arguments in steps and create 
// intermediate functions.

// addTwoNumbersWith1 :: int -> int -> int
let addTwoNumbersWith1 = addThreeNumbers 1

// addOneNumberWith1and2 :: int -> int
let addOneNumberWith1and2 = addTwoNumbersWith1 2

// six :: int
let six = addOneNumberWith1and2 3

Currying and partial application are very powerful features. Currying is the process of transforming a function which takes multiple arguments into a sequence of functions which take one parameter. Applying arguments to a curried function peels off a function from the sequence. This allows you to build reusable functions.

Advent of Code 2016: Things I’ve Learned

I’ve been engaged in the Advent of Code 2016. Attempting to improve upon my solutions from 2015. I have improved a lot since last year. However, as of Day 8 there are some things that I have notably learned. Well, some things I’ve forgotten and learned again. Here are the highlights so far:


This was added in F# 4.0. This function allows you to partition your collection into arrays of a size of your choosing.
For example:

[1 .. 6] |> Seq.chunkBySize 2;;  // seq [[|1; 2|]; [|3; 4|]; [|5; 6|]]
[1 .. 6] |> Seq.chunkBySize 3;;  // seq [[|1; 2; 3|]; [|4; 5; 6|]]

There is a caveat, if the number of items in the collection is not equally divisible by the chunk size, the last array will have fewer items.

[1 .. 6] |> Seq.chunkBySize 5;;  // seq [[|1; 2; 3; 4; 5|]; [|6|]]


This one I seem to forget is available. I always start with a for or a skip |> take and then I remember. It can make your code a lot easier to read.

Spoilers for day 8

I am using a mutable 2D array for day 8. There was a similar problem last year and I chose to go fully immutable and got destroyed by Garbage Collection. Mutability we go! The problem called for shifting pixels (which wrap) on a display. I decided to get the current row of pixels starting at origin (I define the origin as being the length of the array minus the amount we are shifting). I then could apply the shifted row to the mutable 2D array.

My initial implementation:

member this.RotateRow (y,shift) =
  let origin = width - shift
  seq { for i in {origin .. width - 1} do
          yield display.[i, y]
        for i in {0 .. origin - 1} do
          yield display.[i, y] } 
  |> applyShift

It’s not terribly bad. We get the items from shift origin to the end of the array followed by items from the start of the array to origin. We can do better with slicing.

Slicing an array or list is a matter of using the indexer after the label.

let l1 = [1 .. 100];;
l1.[6 .. 10];; // [7; 8; 9; 10; 11]
l1.[7 .. 11];; 
l1.[.. 10];;   // [1; 2; 3; 4; 5; 6; 7; 8; 9; 10; 11]
l1.[95 ..];;   // [96; 97; 98; 99; 100]

Did you notice I said indexer? Yes, slice takes the items via their position in the collection. This is something you will need to be aware of. If you want the first ten items using slice you would use [..9], as the tenth item is in position nine.

Updating my original solution using slices instead of for constructs has made my solution more concise and readable.

member this.RotateRow (y,shift) =
  let origin = width - shift
  seq { yield display.[origin .., y]
        yield display.[.. origin - 1, y] } 
  |> applyShift

By using slices I removed the need to calculate the end of the array. This eliminated the chance of an off by one error. <insert bad off by 2 joke here>


Seq.windowed is handy when you need to look for specific patterns in a collection. This function works by taking a collection and creating a sliding window of arrays with the length you specify.

Some examples of course:

let l1 = [1 .. 5];;
l1 |> Seq.windowed 2;; // seq [[|1; 2|]; [|2; 3|]; [|3; 4|]; [|4; 5|]
l1 |> Seq.windowed 3;; // seq [[|1; 2; 3|]; [|2; 3; 4|]; [|3; 4; 5|]
l1 |> Seq.windowed 4;; // seq [[|1; 2; 3; 4|]; [|2; 3; 4; 5|]]
l1 |> Seq.windowed 6;; // seq [] 

If you try to get windows larger than the size of the collection, you end up with an empty collection.

Seq.chunkBySize, slicing, and Seq.windowed are my three most notable take aways from the first 8 days of Advent of Code 2016.