Wednesday, January 27, 2016

The Book of F#, Chapter 5: Let's Get Functional

This chapter looks at what functional programming really is. In it there are a number of concepts that we’ve either seen in code or alluded to in text as part of the previous chapters, and it was valuable to get more detailed information about things that I had ‘seen but not understood’.

I also feel vindicated for skipping Chapter 4 (for the time being): the author suggests that we should always favour a functional approach when developing in F#, which is precisely the reason that I didn’t want to read about its object-oriented capabilities before understanding its functional core.

Also, the chapter is quite long. As such, I’ll probably write this post in two halves and upload the first once it’s finished, with the second half following a couple of days afterwards.

What is Functional Programming

We’ve touched on this before, but it’s nice to think of functional programming as applying idempotent functions to data. That is, the data structures and objects we create are immutable, and the functions we write will always evaluate to the same output for a fixed input.

Bringing these two concepts together is referential transparency, which encapsulates the situation I have just described by stating that an expression can be directly replaced by its result without affecting the program’s execution. An example would be the ability to replace let x = 2 + 3 with let x = 5, which means that the additional operator + is referentially transparent.

Whilst these are only a couple of functional programming concepts, they are two that make a lot of sense to me, and towards which I like to strive even when writing object-oriented code.

Programming with Functions

F# functions are built from the premise that they always accept a single input, and always return a single output. We discussed this, and the handy unit type, in my previous post, but it comes up again here. Specifically, this fact allows the compiler to assume that the last expression evaluated in the function is the return value, so you don’t have to explicitly specify this with a keyword.

Functions as Data

Similar to delegation in C# is the treatment of functions as data. In F# this is given first-class support, which is one of the features that distinguishes it as a functional language. As a result, we can pass around functions like we can any other object, and we’ll see how useful this is later on in the post. For the time being we will just note the use of ->, which is an infix token that means ‘take something of the left-hand type and return something of the right-hand type’, e.g. int -> int.

The concept of higher-order functions is also introduced here, albeit briefly. To the untrained eye this makes function signatures long and confusing (if you haven’t seen it before, could you possibly understand (string -> string) -> string -> unit?), but hopefully I will get used to it given time.


A lot of detailed stuff is written about curried functions. I am choosing to deliberately simplify my understanding of it as such:

In a language where functions accept exactly one input, currying is how we create things with more than one input.

In essence, if we want to be able to write things like let add a b = a + b, then there has to be something behind the scenes that means this doesn’t type check to a function taking two inputs. This thing is currying, or automatic function chaining, which will look at the statement about and say:

Hey, if add a b needs to return an int, then add a needs to return something that takes b and returns an int.

As you might have figured out, this means the type of add is val add : a:int -> b:int -> int. In English, add is a function that takes an integer a and returns another function. The function it returns takes another integer b and returns a third integer (here a + b).

The author uses a nice trick to show another way of thinking about this: if we write the function as let add a = fun b -> (+) a b, it’s pretty clear that add a returns a function!

This is all very interesting from a theoretical point of view, but it seems to me that in day-to-day development, you really don’t need to know or care that your functions are being curried behind the scenes. Perhaps it helps in understanding the types that are inferred from your code, but beyond that, currying alone does not seem much to write home about.

Partial application

This is another subtle distinction that I really don’t want to get in to. Partial application means that if you call a function with an incomplete set of arguments, it will be evaluated as far as possible.

This seems to have huge benefit for confusion — what if you accidentally miss out a parameter somewhere in your calling code? Rather than not compiling, your work will be valid but ultimately output something of the wrong type, which might be a bit of a shock when you come to use it days or weeks later.

Pipelining and Composition

If I sounded nonplussed about currying, the opposite is true for two other functional features that we are introduced to here.

The ability to send the result of one function to another using one of the pipeline operators (|> and <| for forwards and backwards respectively) seems incredibly useful at first glance. So much of the code that I write comprises half a dozen or so procedural steps, the result of each being passed in to the next statement. The fact that this can be done with an operator in F# is great. Here’s the example from the book:

let fahrenheitToCelsius degreesF = (degreesF - 32.0) * (5.0 / 9.0)

let marchHighTemps = [ 33.0; 30.0; 33.0; 38.0; 36.0; 31.0; 35.0;
                   42.0; 53.0; 65.0; 59.0; 42.0; 31.0; 41.0;
                   49.0; 45.0; 37.0; 42.0; 40.0; 32.0; 33.0;
                   42.0; 48.0; 36.0; 34.0; 38.0; 41.0; 46.0;
                   54.0; 57.0; 59.0 ]
|> List.average
|> fahrenheitToCelsius
|> printfn "March Average (C): %f"

Simple, clear, and so much nicer than object-oriented code!

Similar in nature and style is the concept of function composition, which takes two functions and returns a third. Keeping with the example above, we could define

let averageInCelsius = List.average >> fahrenheitToCelsius

which binds two steps of the computation in one function. Pretty damn cool!

I reckon these two features, combined together and in the right project, could be reason alone to pick F# over C#. It’s a bold statement, but notice I said in the right project. I can foresee that in a lot of applications, this kind of syntax won’t be use nearly often enough to reap any reward.

Recursive Functions

We said in the previous post that recursion is the preferred method of looping in a functional language, and now we’ll get to see why, and how.

What I (naïvely) didn’t realise is that all the traditional lopping constructs (while, for and foreach) rely on a chance in state to terminate, and so don’t really mesh with pure functional programming so well. Instead, if we have a recursive function that calls itself, all we need is some base case that causes it to eventually terminate.

This looks very similar to induction to my maths brain, in that we say what to do in the base case as well how any other case relates to it’s predecessor (i.e. the inductive step).

In F#, we do recursion with the rec keyword. The example given is the classic factorial computation:

let rec factorial v =
  match v with | 1 -> 1
               | _ -> v * factorial (v - 1)

This reads almost as-is: if the input is 1 then return 1, otherwise return v times the same function called with v - 1.

On the negative side, this is not tail-call optimised, and is the kind of function that gave rise to the most famous of programming websites, Stack Overflow. Basically, writing the function like this means that if we start with a really big number, we will end up with a new stack frame for each function call, which will cause a Stack Overflow!

We get around this fairly simply by ensuring that the recursive call is done last (it might look like this is the case for our current implementation, but it’s actually the multiplication operation that end up in the tail position). One way to do this is by keeping track of both the current number we are ‘down to’ as well as the product computed so far:

let factorial v =
  let rec fact current product =
    match current with | 0 -> product
                       | _ ->   fact <| current - 1 <| current * product
   fact v 1

As shown here, this form will allow the program to use a JUMP statement or similar and replace the arguments to fact on each iteration, rather than calling the function again.

Whilst you can obviously write a recursive function in C#, the compiler doesn’t support tail recursion, so this gives F# a big thumbs up from me.

Mutually Recursive Functions

I’m not entirely sure how often I will use this concept, but as the name suggests, two functions can call each other recursively. The example from the book is the fibonacci sequence:

let fibonacci n =
  let rec f = function
          | 1 -> 1
          | n -> g (n - 1)
  and g = function
      | 1 -> 0
      | n -> g (n - 1) + f (n - 1)
  f n + g n

Nice, but I cannot immediately think of an example in my current work where I would use this.

Lambda Expressions

These are something that are very familiar to me, as they are used extensively in C#. They seem pretty similar in F# to be honest, using the same -> token and with broadly similar use cases (i.e. when we have inline expressions that are only ever used in a very narrow scope.

Next Time

I’ll leave it there for the time being, and finish this post off within a few days. Here’s a sneak peek of what’s left to cover in this chapter.

  • Closures
  • Functional Types
  • Discriminated Unions
  • Lazy Evaluation
  • Summary


As promised (though a week or so after originally planned), it’s time to finish off my overview of what functional programming comprises. It looks like the book is quite in-depth at parts, so I will skip anything that is more details than necessary.


These are a big feature that I’m already quite familiar with from C#, and are quite well documented (see this post by Jon Skeet as an example).

In a nutshell, they allow a function to capture a value that is visible to it, even if it’s not part of the function. A good example of this is something that increments a global counter:

let g() = 
    let mutable counter = 0;
    fun () -> counter <- counter + 1

The only thing I noticed here was something that I first encountered back in Chapter 3: as of F# 4.0, you can mutable keyword for values that change inside closures. Beforehand this wasn’t possible and you needed a reference cell instead.

Functional Types

This rather long section boils down to Tuples, Records, and a lot of syntax. On first reading this, I thought there was a lot to take in. However, I since read some notes the form part of the University of Washington’s Programming Language Course which explained that tuples are just syntactic sugar for records with particular component naming conventions. I will talk a lot more about this when I eventually go through those notes in a subsequent post, so here I will focus more on the F# syntax rather than the more precise semantics.


Tuples are a way to group an arbitrary number of values in a single construct. In F# they are created by separating their arguments with ,, and have a type signature where elements are separated by *:

> let tuple1 = 1.0, "hello";;

val tuple1 : float * string = (1.0, "hello")

They are also, as of .NET 4, in C#. I haven’t worked with them much in a C# context as rather than writing stuff like

var tuple = new Tuple<string, int>("Doug", 28)
Console.WriteLine(tuple.Item1 + ": " + tuple.Item2)

I would rather write

var person = new Person("Doug", 28)
Console.WriteLine(person.Name + ": " + person.Age)

The second version makes it so much more obvious what’s going on.

In F# they seem to have much better first-class support (probably because F# is based off ML, which has first-class tuple support), and so are a bit easier to work with. There are still limitations, though. You can access the first and second elements of a pair with fst and snd, but to access all three elements of a triple you would have to use Item1 etc. or deconstruct the tuple:

let triple = "Doug", 28, "London"
  let name, age, city = triple 
  in (...)

Essentially, you construct only to deconstruct at first use, which doesn’t immediately chime with me.

It’s worth bearing in mind how often tuples are used within F#, though. Consider calling a .NET library function that takes two arguments. We’ve seen already that every function in F# takes in one arguments and returns one result. So how can we call String.Format, for example? Using a tuple! F# converts the function signature of things like this to be a function from the required tuple type, to the output type. This gives the illusion of calling things in C# style, which provides some comfort I suppose.

Furthermore, F# uses tuples in place of out parameters. To be honest, I don’t like using these in C# (the TryGetxxx functions make me squirm!), but using the magic of tuples F# can return two results that are boxed up into one:

let parseSuccessful, parsedValue = Int32.TryParse "10"

This, I admit, is nicer that C#. I’ve already written too many custom return structs for functions where I want to return more than one thing, and F# solves these issues in a trifle.

So, tuples are great for returning stuff and calling .NET library functions, but look a bit rubbish when explicitly creating them yourself.

Record Types

I’ve already said that tuples are just record types with a special syntax. So what does one look like in F#?

type person = { Name : string; Age : int; City : string }

Isn’t this exactly what I wanted earlier in C# and wrote a class for? Yes it is! We get the best of both world here, in my opinion: creating custom data types without needing whole classes, and being able to access the bits of a class in a strongly-typed and clear manner.

There are a few other syntax bits with tuples that might be useful: you can do a ‘copy and update’:

let doug = { Name = "Doug"; Age = 27; City = "London" }
let itsMyBirthday = { doug with Age = 28}

You can also declare individual bits of a tuple as mutable, but that sounds like a road I’d rather not go down given that I am trying to learn a relatively pure functional paradigm.

Finally, you can add a member to a record:

type person = { Name : string; Age : int; City : string }
              member x.Description() =
                x.Name + " lives in " x.City 

This is because they are syntactic sugar for classes! All along we really wanted a Person class, and now we have it. But we also have a really nice way of declaring it, and excellent type-safety.

Discriminated Unions

Returning to the UW Programming Languages course, we can now see that tuples and records are ‘each of’ types.

The F# version of a ‘one of’ type is the discriminated union. This is something where the values are restricted to be one of a set of cases. Each case can be of any type, and these can be recursive:

type Tree =
    | Empty
    | Node of int * Tree * Tree

The above type says that a tree is either the tip of the tree, or it is a node that has a value int, and left and right Tree instances.

This is another area that I’ll cover in more detail when I go through the UW course in a future post, but I think it’s still useful to know now that all this data type is doing is providing us with a way to ‘tag’ data with it’s type, so in the above example we can say that something that’s empty is really Empty, and something that looks like int * Tree * Tree is really a Node.

As of F# 3.1, you can actually create instances of these types using named arguments, so we might have actually written

type Tree =
    | Empty
    | Node of value : int * left : Tree * right : Tree

let newNode = Node (value = 3, left = EmptyTree, right = EmptyTree)

The power of discriminated unions is really in their ability to be pattern matched. As an example, summing the nodes of the tree could be done as:

let rec sumTree tree =
    match tree with
    | Empty -> 0
    | Node(value, left, right) ->
        value + sumTree(left) + sumTree(right)

let myTree = Node(0, Node(1, Node(2, Empty, Empty), Node(3, Empty, Empty)), Node(4, Empty, Empty))

let resultSumTree = sumTree myTree

I don’t think I’ve ever summed the contents of a tree in C#, but it would definitely have more if or switch statements than that!

The final couple of points on discriminated unions are that they can be convenient aliases, and they can be extended with additional members. Coincidentally, I have been reading Eric Lippert’s blog series on OCaml and in one of the posts he uses a very similar aliasing technique to ensure type safety when passing around primitive stuff. That is, we could treat a binary tree value as

type NodeValue = NodeValue of int

In a more complex module, this would prevent us passing in another random int as a node value (e.g. the height of the tree). This syntax is so helpful and so lightweight, I am amazed it isn’t more ubiquitous in programming languages.

Lazy Evaluation

This is another feature that has made it across to C#. Once again it’s something I haven’t used explicitly that much. However, I am familiar with the concept from things like IEnumerable<T>.

In F#, we have syntactic support for lazy evaluation with the lazy keyword, which creates an instance of Lazy<T> that can be executed using the Force() function or Value property. There’s not much more to say at this stage, lazy evaluation is a useful concept and simple to implement in F#!


There was a lot in this chapter. Some of the concepts made a lot more sense after reading around the topic, espeically in the area of tuples, records and discrinimated unions. Yet further topics were already familiar from C# such as closures and lazy evaluation, and others from my brief forays in to Haskell such as currying and partial application.

The topics slowly sink in, but will take more time! Next up I will break away from the book and go back to some more academic and basic principles to cement my knowledge as well as do some real exercises.

Saturday, January 23, 2016

The Book of F#, Chapter 3: Fundamentals

In some sense, Chapter 3 is the first ‘real’ chapter of this book. In it, we are given a whirlwind tour of a large number of F# facets, some more interesting than others.

What is clear to me though is that you need a decent knowledge of .NET to really understand the content, especially in the sections on Generics and Exceptions.

Immutability and Side Effects

If you’ve studied functional programming before, there will be no surprises here: bindings are immutable by default, and side-effects (in general) need to be explicitly permitted.

I think this is great for two reasons. The first is the usual one: once something is assigned to, you know that its value won’t ever change and so reasoning about it is much easier. The second is more architectural: you end up putting the right things in the right places. If a quantity needs changing after it’s been created, is it really the same quantity?

A basic example would be the Builder Pattern from the object-oriented world. That is the antithesis of immutability and gives you the option to muck around with your object as much as you like, even after construction! There are plenty of ways to have immutable objects in C#, especially now we have getter-only autoprops in C# 6.0, but having a language that won’t let you do it another way is so much nicer!

Another point, which the author raises on this topic, is thread-safety: if something can be changed and can also be accessed simultaneously by multiple threads, who knows when and by what it might be mutated.

Functional Purity

Having said the above about side-effects and immutability, there’s a bombshell: F# is impure! Shock horror for a language that has access to the whole .NET Framework.

What this basically means is that whilst the default case is for functions to be pure, that is to consist of expressions that always return a value with no side effects, you can ask F# to allow variables to be mutated.

Whilst this allows you to write code a lot more easily, you lose the ability to fully reason about your functions as they lose idempotence. I’m taking the decision now that this sort of mutation is bad, and will try and do as little as possible of it! In cases where it seems as though some kind of application-level state is required, I’ll do my best to replace the stateful behaviour with something else.


These are how F# determines values or executable code.

The first is the let binding, which associates a name with a value and seems very flexible — you can bind an int, string, function or result with let. let bindings are immutable and are treated like readonly in C#, not as constants. Compile-time constants are instead declared with [<Literal>]. This seems slightly strange: what was wrong with the const modifier?

If you want to be naughty and change your variables, you can allow with the mutable keyword, changing the value with <-. As of F# 4.0, we can also use the mutable keyword for values that change inside closures. Why you would ever want this is beyond me, though!

Now for a slightly more complex concept, the reference cell. A reference cell, which you might declare with let cell = ref 0 encapsulates a mutable variable which we access using ! and change using :=. That’s what the book says, anyway. I still don’t quite get it, in particular why you would want to use it, especially when you consider that when you do something like (example from here):

let cell = ref 0
let cell2 = cell
cell2 := 1

then the value of cell also becomes 1! To me this is confusing and potentially dangerous.

Secondly, we have the use binding: this is similar to using in C# in the sense that it’s for things that implement IDisposable, and those things get disposed automatically when they go out of scope. It’s also worth noting that you can’t use them inside a Module and will get a warning saying that they are treated as let bindings in this context. Essentially this is because modules are treated as static classes that are always in scope.

You can also write using as in C#, and it’s actually more powerful than the C# as things in F# always return a result, so you can assign to variables directly from the using block rather than inside it.

Finally, do bindings execute code outside of a function of value context. This seems to be useful when doing things like initialisation and constructor calling, and I’m sure plenty of other scenarios that I haven’t yet come across

Identifier Naming

This one’s short: we can enclose a string in "", which is helpful for unit testing as we can say things like let "MethodName_StateUnderTest_ExpectedBehaviour" = ....

Core Data Types

This is really just a list of syntactic differences between F# and C#:

  • Uses not rather than ! for boolean negation.
  • Numeric types are the same as C# with some abbreviation and suffix changes.
  • There is a new operator!! ** is the exponent operator, which seems very handy for mathematical programs: Math.Sqrt(Math.Pow(x,2.0)+Math.Pow(y,2.0)) no more!
  • We also have&&&, |||, ^^^, ~~~, <<<, >>> for bitwise AND, OR, XOR, negation, left shift, right shift.
  • There are no implicit type conversions for numerics as they are considered side effects, so we can’t divide a float by an int and expect it to work.

Type Inference

The type inference capabilities of F# are such that newcomers often mistake it for a dynamically typed language. C# also has type inference (var) but it is very limited.

I think this is probably far too detailed a topic to go into now, but if we copy the example from the book, the upshot is that creating a person with three properties in F# requires exactly three explicit type declarations:

type Person (id : System.Guid, name : string, age : int) =
member x.Id = id
member x.Name = name
member x.Age = age

This appeals to my DRY sense of (humour) programming. We already know the age is an int, why should we have to tell the computer that in both the constructor and the property definition?

You can add a type annotation as well if the compiler gets confused, so something like let x : float = 2.0 .


Null is almost never used in F#. To use it, include the [<AllowNullLiteral>] attribute. It’s only really there for .NET interop. Overall this should reduce NullReferenceException instances and null checks.

All this is fantastic. Even with the addition of the null conditional operator in C# 6.0 (represented either by ?. or ?[ depending on if you are accessing a member or an indexer), it’s still annoying to have to ask if something has a null reference all the time.

F# also caters for stuff that might genuinely not have a value: it has the type Option<'T> which is a discriminated union of Some('T) and None, and has its own keyword (e.g. let middleName : string option = None).

This falls through to functions as well: an optional parameter is denoted with ? and given a default value with defaultArg. The defaultArg function accepts an option as its first argument and returns its value when it is Some< _ >; otherwise, it returns the second argument. I’m not so sure I like this syntax as much as the C# version where you just write argName = defaultValue in the method signature, that seems cleaner than specifying this:

type T(?arg) =
  member val Arg = defaultArg arg 0

Lastly, for things that evaluate only for a side effect, there is the unit type, whose value is written as (). This is a concrete type that signifies that no particular value is present, so the result of any expression can safely be ignored.

If we get back something that’s not unit and we don’t use it (bind it or pass to another function), we get a compiler warning. This can be removed by piping (|>) the result to ignore.

Flow Control

The author is quick to point out that recursion is the preferred looping mechanism in F#, but that there are imperative constructs as well:

While loops, written as As a notable aside, the body of the loop must return unit, reinforcing the point that expressions return values!

For loops:

for i = 0 to 100 do... — standard for loop
for i = 100 downto 100 do... — making it count downwards

for i in [1..10] do... — the equivalent of foreach in C#, this works on enumerated types. What surprised me was that this is actually a syntactic shortcut for pattern matching. I am presuming that this is translated to something that matches on i and does nothing if it is less than 0 or greater than 10. I’m going to skip the details of pattern matching for now as it’s covered in later chapters.

Note that we don’t have break orcontinue keywords to force early termination of loops. This is strange and will definitely require some care when creating certain kinds of loop.


This is slightly different to C# and uses the syntax if ... then ... else, or if...then...elif...then...else. The nice thing about them is that because they return a value, we don’t need to either pre-assign a variable or use a ternary operator, e.g.

// Using a pre-assigned variable;
bool found;
  found = true;
  found = false;

// Using ternary operator
bool found = condition ? true : false;

In F# this would be something like

let found condition = 
  if condition then

This is a contrived example and so actually looks a bit messy in F#, but I can see how this works well for more complex branches. Another point to note is that when only an if branch is specified it must evaluate to unit, otherwise each branch must evaluate to the same type.


As a C# dev, I love generics. Thankfully, their creator also happens to be the F# language designer, Don Syme, and so F# gets first-class support for them too.

Generics allow type-safe code that works with multiple data types, generating implementations based on the input type — consider the difference between ArrayList in which everything is System.Object and List<'T> where the type is clearly disambiguated.

In F#, generics are named with a leading apostrophe ('a, 'A, 'TInput). F# prefers automatic generalisation e.g.

let toTriple a b c = (a, b, c);;
val toTriple : a:'a -> b:'b -> c:'c -> 'a * 'b * 'c

To do useful things with the types, we need constraints (written as when). We inherit all the ones from C# (ref types, value types, those with a default constructor, those that derive from a class or interface) but also F# adds a few more. There’s loads of examples in the book so I’m only going to copy a few in here.

// Fairly standard constraint from C#: we need a parameterless constructor
let myFunc (stream : 'T when 'T : (new : unit -> 'T)) = ()

// Interview question alert!! This works only on comparable types
// which is of course the constraint on sorting algorithms.
let myFunc (stream : 'T when 'T : comparison) = ()

There are a couple of other syntax elements to look at: flexible types are a shortcut for subtype constraints, and are denoted by #: let myFunc (stream : #System.IO.Stream) = ()

To use a generic type as a parameter and let the compiler infer the type, use <_ >: let printList (l : List<_>) = l |> List.iter (fun i -> printfn "%O" i). This will print the result of evaluating the ToString method on whatever type is passed in the list.

One final thing that is specific to F# is the ability to statically resolve generics. These are resolved at compile time and are primarily for use with inline functions (that is, those that are directly integrated into the calling code and/or custom operators. The implication is that the compiler generates a version of the generic type for each resolved type rather than a single version, so be warned!

We declare these using ^ rather than an apostrophe, for example:

// All types where null is valid
let inline myFunc (a : ^T when ^T : null) = ()

// Custom operator, resolves at compile time to ensure all types
// that use it have a Pow operator implementation
let inline (!**) x = x ** 2.0

Overall, it seems like generics are pretty powerful in F#, which is a bonus to me.

When Things Go Wrong

There are two exception constructs in F#: try...with and try...finally (i.e. we have no try...with...finally block). If you need both then use a try...with within a try...finally.

The exception is captured with as and will pattern match against the type of exception, which we do with :?. In total, this gives us something like:

open System.IO

  use file = File.OpenText "somefile.txt"
  file.ReadToEnd() |> printfn "%s"
| :? FileNotFoundException as ex ->
  printfn "%s was not found" ex.FileName
| :? PathTooLongException
| :? ArgumentNullException
| :? ArgumentException ->
  printfn "Invalid filename"
| _ -> printfn "Error loading file"

My first impression is that this is a more terse and compact block than the C# equivalent, and still very readable even to someone new to the langauge.

To partially handle an exception we use raise or reraise — the former loses the stacktrace and so probably isn’t that desirable, but the latter is only valid in a with block, so both are required depending on the exact circumstance.

Return values com up again here: try...with returns a value. You can return things other than unit, but all cases must then return the same type. Commonly we use the Maybe monad in this case (i.e. the DU of Some<_> and None).

We also raise our own exceptions with raise, but there are additional syntactic helpers: failwith and failwithf , which take in strings as the exception’s message:

if not (File.Exists filename) then
  failwith "File not found"

if not (String.IsNullOrEmpty filename) then
 failwithf "%s could not be found" filename

We can create our own exceptions by deriving from exn, which is shrothand for System.Exception, or use the incredibly lightweight syntax provided by the exception keyword:

exception RetryAttemptFailed of string * int
exception RetryCountExceeded of string


There was a lot of syntax to take in as part of this chapter. I will admit that most of it didn’t register the first time, but having come back to it whilst writing this post, a lot more makes sense.

The things that stuck with me were default immutability and type inference. Both features seem incredibly powerful if harnessed correctly, so I guess I have to learn how to do that next!

Next time, I’m going to be covering Chapter 5 (Let’s Get Functional). This is because the contents of Chapter 4 cover object-oriented programming in F#, and I’d rather get functional-first thinking drilled into my head before learning how to do OO stuff in another language. Hopefully this will keep my brain progressing down the road towards functional thinking!

Tuesday, January 19, 2016

The Book of F#, Chapter 2: F# interactive

This one’s going to be brief!

Chapter 2 covers how to use F# Interactive, which is a nice REPL (read–eval–print loop) shell that can run inside Visual Studio, or on its own.

It’s fairly simple: you type the code you want to execute, terminating each statement with ;; to execute it. As well as outputting the return value of your statement (which will be bound to the name it if you don’t specify a binding, it also prints that data type of the value. I suspect this will be useful when prototyping code, playing around with expressions in a shell to try and get the right data structure sounds a lot easier than trying to manipulate the source file!

There are also a bunch of directives that enrichen the tool, and allow you to do things like load the code from file with #load or load an entire assembly with #r.

Finally, rather than standard F# source files (with the .fs extension), you can also create script files (.fsx) which can be executed directly by F# interactive.

So overall it’s a nice thing to have, but nothing to write home about.

Next time, we’ll get into the meat of the F# syntax when we explore the fundamentals of the language.

Sunday, January 17, 2016

The Book of F#, Chapter 1: Meet F#

This chapter is really covering the basic points about how to lay out an F# file, and what the language does at a high level. That said, there are some pretty big differences from C# that are worth pointing out.

As well as being a functional-first language, F# is a full-featured OO language with some imperative constructs also available. I’m not sure whether this will turn out to be something that I like or not, but it’s worth bearing in mind.

Files and (lack of) folders

In terms of immediately noticeable things, there are a couple of quirks with the project hierarchy: there are no folders, and files are executed in the order in which the appear in the project. Thus, dependent items must be declared in files below their dependencies.

The benefit of this is that the compiler can infer much more about your code and give unrivalled type inference. It also avoids recursive definitions. Both of these seem like good things! I haven’t been caught out by the execution order yet but I’m sure that day will come.

Though not explicitly stated in the book, it also seems to encourage the user to create small projects . Imagine a project that has 5 folders, each with 5 source files in — a fairly common occurrence in C#, but the idea of having 25 files in a single-level hierarchy and making sure they are in the right order scares me.

Whitespace matters

Whitespace is also significant - code inside a block must be further indented than the opening line. I’ve found this to be annoying, to be honest. I can understand the reasoning behind it (no curly braces!!) but I’m just not used to it yet. This is especially obvious when pasting in code snippets from the book: having to change the indentation of the block block can be cumbersome. A simple example of this nesting from the book is:

let isEven number =
  if number % 2 = 0 then
    printfn "%i is even" number
    printfn "%i is odd" number

We can group by namespaces and modules. Namespaces look pretty much as they don in C#. To my eyes, a module looks analogous to a C# class, but I might prove to be mistaken by the end of the book!

It returns results!

The next important point is that F# is an expression-based language; nearly everything that is evaluated returns a result. This contrasts with C# where only non-void methods do so! One corollary of this is that basic blocks such as if statements need to be looked at in a different light: they return a result! Going back to the previous code snippet, it means that we can write the routine as:

let testNumber = 10
let evenOrOdd = if testNumber % 2 = 0 then "even" else "odd"
Console.WriteLine evenOrOdd

In this simple example we could have done the same in C# using the ternary conditional operator

var evenOrOdd = (testNumber % 2 == 0) ? "even" : "odd";```

but that’s certainly not so in more complex scenarios.

Entry Points

Getting into an application is a bit different too: we define an [<EntryPoint>], rather than a Main method in C#. This is a bit nicer for me than C# as it gives more control over naming:

let MyProgram argv =
  // do some stuff

It’s also worth noting that here, as everywhere else in F#, the compiler assumes that the last expression evaluated is the return value. This means we don’t need to use a return keyword. I’m undecided on this one yet, as I think that using return makes it really obvious when you want to exit a routine.

The Reverse Polish Notation calculator

The chapter finishes with a great example that showcases some of the most powerful features of F#: pattern matching, concise syntax, type inference, and recursion. It introduces a basic parser that can take a string defined in Reverse Polish Notation and perform the required computation.

This would normally be done by creating a mutable stack and pushing/popping from it:

  • split the string into a list of characters;
  • push characters onto the stack until we see something that looks like an operator;
  • when we get an operator, pop twice from the stack (these will be numbers);
  • apply the operator to thee two numbers;
  • push the result onto the stack;
  • repeat until our input list is empty;
  • pop the last remaining number from the stack, which is our result.

I’m not going to write the C# code for this, but it would no doubt require an Enum for the operators, a Stack<int>, a while loop, and some other stuff. What I will do is copy the code from the book (which can be found from the book’s homepage if you want to dig into them:

module TheBookOfFSharp.RpnCalculator

open System

let evalRpnExpr (s : string) =
  let solve items current =
    match (current, items) with
    | "+", y::x::t -> (x + y)::t
    | "-", y::x::t -> (x - y)::t
    | "*", y::x::t -> (x * y)::t
    | "/", y::x::t -> (x / y)::t
    | _ -> (float current)::items
  (s.Split(' ') |> Seq.fold solve []).Head

No stack, no loop, no enum.

It’s different, for sure, and if you’re new to F# and functional programming in general I bet you’ve got no idea what’s going on!

Let’s say the input to this function is the string "4 2 5 * + 1 3 2 * + /". The first thing that happens is it gets turned into an array of characters via (s.Split(' ').

So far, so C#. What happens next is a bit trickier to read: the array that we’ve just created gets sent to the function Seq.fold as its third parameter (the function solve is the first, the empty list [] is the second).

What this will do is recursively call solve taking in a list called items (think of this as our stack!) and a single value from our original array of characters, and do this until there’s nothing left. The empty list just tells it what to initialise items to.

Lastly, the solve function does the business. It uses pattern matching (match) to say that: if we have an operator (one of "+", "-", "*", "/") as the incoming current character, and if the items list has at least two things in it (i.e. it is of the form y::x::t), then remove the first two things in items, apply the operator to them, and stick the result back on the front. In the case that we don’t match this pattern (i.e. we have a number), just stick that in items.

Running through our example, we will therefore:

  • Put 4, 2 and 5 into items
  • Take 5 and 2 out, multiply them (*), and put the result (10) in
  • Take 10 and 4 out, add them (+), and put the result (14) in
  • Put 1, 3 and 2 in
  • Take 2 and 3 out, multiply them (*), and put the result (6) in
  • Take 6 and 1 out, add them (+), and put the result (7) in
  • Take 7 and 14 out, divide them (*), and put the result (2) in
  • Finally, the Head command tells us to take the first things out of items: our answer, 2. (It works!!!)

Writing it in prose like I have just done, it sounds very similar to the enum/stack/loop form that we thought we didn’t have! Implicitly, of course, we still have all of these items, but it is striking to notice how we can express the computation in very different constructs.

Wrapping up

Most of what was in this chapter is ‘information only’. That is, it’s really useful to know, but there are no real ‘wow’ moments.

The example at the end of the chapter was somewhat more involved than I was expecting, and took me a few minutes to figure out what was going on. Once you see it, the code looks terse and elegant. Until that point, however, it feels slightly impenetrable to the outsider.

Next time, the F# interactive tool!

The Book of F# - Introduction

In my previous post I said that, as a means of reinforcing my own learning, I would be going through The Book of F# and giving my own thoughts on what’s inside.

Before I dive into the contents, let me answer a few questions.

What do I know already?

I’ve been programming in C#, the object-oriented big brother of F#, for the past two years. Whilst I am not yet expert in the language, I feel able to express what I need to in C# code.

On the other hand, I don’t feel fully comfortable with the object-oriented (OO) paradigm . My view on what software does is (perhaps overly) simple:

Data comes in one end, gets acted upon, and goes out the other.

The astute observer will notice that, whilst not incompatible with OO principles, this view is closer aligned to Functional Programming. The amount of scaffolding required to do a simple computation in C# often surprises me, and feels inefficient.

This combination makes F# attractive: a functional-first language that harnesses the power of the .NET Framework sounds like a great mix of simplicity and familiarity.

To boot, I also did Erik Meijer’s fantastic course on edX, Introduction to Functional Programming. This introduced me to some concepts that seemed to align closer with my logical reasoning about software, things like pattern matching and recursion.

Complicating matters further, my favourite bit about programming C# is having access to the System.Linq Namespace. Note the precise vernacular — I didn’t say that my favourite bit was LINQ (which I have never used, and never intend to), and I also said ‘having access to…’. This is because the bits that I like are actually part of the .NET Framework, and so can be used by any language that runs on the CLR, including F#! (yes, I know that they can’t be used in the same way because they use C#’s extension methods, but we’ll come to that).

So here I am: a C# developer that doesn’t quite feel natural writing fully object-oriented code, loves the functional-style of the extension methods on IEnumerable<T> with their expression trees and lambdas, and has had a taste of ‘pure’ functional programming via some basic examples in Haskell.

Time to go functional, then?

Why am I learning F#?

It’s quite a simple reason, in a way. There are bits of C#, bits of .NET, bits of functional programming, bits of object-oriented programming, all of which I think are great. Wouldn’t it be awesome if there was a language where I could use all of them?

And that is the question I am truly asking: is that language F#? On the face of it, it could be. On the other hand, it could be that it combines the worst bits about all that I mentioned above! It’s worth figuring out, though.

What am I trying to get out of the book?

The answer to my question!

This may be flippant, but it sums it up. I’m looking at the book as a window into the language from the perspective of an experienced C# developer:

  • How does the syntax compare: it is more natural, less natural, or about the same?
  • What about functionality: how does it integrate with the .NET Framework?
  • Does it help with writing complex or long-winded calculation routines?
  • How are the elements of functional programming and object-oriented programming interleaved?
  • Is it possible to build enterprise applications with it?
  • Are there enough tools available to ensure code quality?

These can be combined:

Would I write a new project in F#?

If I can give a good answer to that by the end of the book, I will be happy.

And so to the book.

The Foreword and Preface got me hooked straight away. Both the author Dave Fancher and the technical reviewer Brian Hunter talked about their journey into F# in strikingly similar fashion to my spiel above. Dave was a C# developer who loved LINQ but hated the verbosity of C#; Brian is another functional convert who is furthermore convinced that OO programming is harmful, spreading of the dangers of mixing data with behaviour.

The best sentence was actually a printing of someone else’s quote, so I will cross-reference it here (source Joe Armstrong):

“You wanted a banana, but what you got was a gorilla holding the banana and the entire jungle.”

That chimes with some of my gripes about C# — I find it a constant struggle not to end up passing around references that refer to, essentially, an entire jungle.

Next came a short introduction, where we learnt about F#’s interoperability with other .NET langauges as well as its functional-first approach. Again, these are two points that really make the language appeal to me. I already use lots of the .NET framework (familiarity), and am able to tie in functional concepts with my own way of logical thinking (simplicity).

From here, the book is organised into twelve chapters, each building on the last. To help move around them, here’s a copy of the table of contents, with links updated as I write the posts:

After these are all done, I’ll refer back to this post with an answer as to whether I would use F# for a new project or not.

Saturday, January 16, 2016

Another Kind of Training

It’s safe to say there’s been more action in my life off this blog than on it for the past few years. Cycling has been and gone; I’m sure it will return at some future date.

What is here to stay though, is code. Software is eating the world and I am no exception — what started off as a means to an end is now a nascent career as I’ve been working as a Software Developer for just over two years.

There are tens of thousands of software blogs already out there, yet here I am starting up another.


In this decade there is such proliferation of information. It has been quoted that we see more information in one day than our ancestors saw in their lifetimes. I find myself more and more often asking myself: how much of what I’ve read, watched or listened to has actually sunk in?

I suspect the answer is not very much. As someone who thrives on knowledge and learning, this frustrates me. What do I have to show for the ten hours a day spent at work writing code, reading blogs and articles, not to mention the time spent generally skimming twitter for other interesting developer tidbits? In the past year alone I have ‘learnt’ so much, only for most of it to fail to penetrate my long-term knowledge base. To give this some scale, I’m pretty sure I’ve watched all of the videos, done all of the courses, and read all of the books listed below:

Online Courses

Exploring C# 6 with Jon Skeet
Algorithms: Design and Analysis
Erik Meijer: Introduction to Functional Programming
M101N: MongoDB for .NET Developers

Other videos

Martin Fowler: Introduction to NoSQL
Joshua Bloch: How To Design A Good API and Why it Matters
Brian Fitzpatrick & Ben Collins-Sussman: The Myth of the Genius Programmer
Robert C. Martin: Clean Architecture and Design
Jon Skeet: Abusing C#
Dr. Don Syme: Introduction to F#


Sam Newman: Building Microservices
Pramod J. Sadalage & Martin Fowler: NoSQL Distilled
Glenn Block et. al.: Designing Evolvable Web APIs with ASP.NET


Martin Fowler: Bliki
Eric Lippert: Fabulous Adventures in Coding
Mark Seeman’s blog
The Clean Code Blog by Robert C. Martin

… and plenty more that I have forgotten entirely, not to mention those unrelated to software development!

This is where my blog renaissance comes in. Whilst I have ‘done’ all that listed above, my Definition of Done has been pretty nonexistent. I’ve made some notes, done a few exercises here and there, but most just passively watched a video or read an article and promptly forgotten 90% of the content.

Not any more.

From here on in, I will be consuming less, but learning more. When I dive into an in-depth book, online course, multi-part blog topic or video lecture, it’s going to be distilled here: a book will have a chapter-by-chapter breakdown; a course will have a précis of the lectures along with exercise solutions; the salient points of a blog series will be summarised.

All of this will be for one reason, to ensure that I really learn this stuff. The act of crystallising and expressing my thoughts on a topic will require me to understand it at such a deeper level than just passive reading or viewing. Hopefully, along the way, people will read this and learn something too. Or at least very least, correct my mistakes and start up some engaging conversations.

So without further ado, let me introduce the first topic:

The Book of F#

Over the next eight weeks I’ll be going through the book, poking at its contents and summarising what I’ve learnt on here. I’ll explain why I’m going through this book, what I’m trying to get out of it, and how I will be doing so.