-- "Functor f =>"  just means that `f` refers to a functor type (or a type of box)
fmap :: Functor f => (a -> b) -> f a -> f b 

ghci> fmap succ (Just 4)
Just 5
ghci> fmap (^2) (Just 4)
Just 16
ghci> fmap (++"!") getLine
Hello World
"Hello World!"

All these calls map single argument functions over functors, which is neat, but a bit limiting. What happens if we map a two (or more) argument function like +?

ghci> :t fmap (+) (Just 4)
fmap (+) (Just 4) :: Num a => Maybe (a -> a)

This gives us a +4 function in a Maybe context, so fmap (+) (Just 4) = Just (4+). But how do we pass the second argument to this boxed up function? We can’t use fmap again, because it’s signature takes an (a -> b), not a f (a -> b). But if f is not just a functor, but an applicative functor, then we have another option. Applicative functors still support fmap, but also add some other functions, the main one being:

(<*>) :: Applicative f => f (a -> b) -> f a -> f b

The bizarre-looking <*> function takes a boxed-up function a -> b and applies it to a boxed-up a, which is just what we need in this case.

ghci> import Control.Applicative  -- imports (<*>) function (et al.)
ghci> fmap (+) (Just 4) <*> (Just 10)
Just 14

Applying applicatives

Just as fmap lets us map a function over a value in a context, <*> applies a function in a context to a value in a context. It ends up mirroring standard function application, only within a context:

ghci> let sum3 a b c = a+b+c
ghci> sum3 5 10 15
30
ghci> fmap sum3 (Just 5) <*> (Just 10) <*> (Just 15)
Just 30

The initial fmap call lifts sum3 into the new context (puts it in a box, in this case the Maybe type), then we apply that boxed function to its remaining arguments while staying in that context.

Because this is a fairly common pattern, the Control.Applicative library defines the function <$> as an alias for fmap:

ghci> sum3 <$> (Just 5) <*> (Just 10) <*> (Just 15)
Just 30

Using this syntax we can apply functions with any number of arguments within a context. We apply each argument using <*>.

Lifting functions

There are also some convenience functions, liftA, liftA2 and liftA3 to convert 1, 2 and 3 argument functions that take applicative functor values. From the Haskell source:

-- For unary functions:
liftA :: Applicative f => (a -> b) -> f a -> f b
liftA f a = pure f <*> a

-- For binary functions:
liftA2 :: Applicative f => (a -> b -> c) -> f a -> f b -> f c
liftA2 f a b = f <$> a <*> b

-- For ternary functions:
liftA3 :: Applicative f => (a -> b -> c -> d) -> f a -> f b -> f c -> f d
liftA3 f a b c = f <$> a <*> b <*> c

This lets us use standard function syntax for calling our functions within a context.

ghci> liftA3 sum3 (Just 5) (Just 10) (Just 15)
Just 30

Well-behaved applicatives

Just as there are laws a functor must satisfy, applicative functors have some additional requirements.

First up, as they are defined in Haskell, applicatives have to not only supply a <*> function, but also a pure function, which will take a value and put it in the context of the applicative functor:

pure :: Applicative f => a -> f a

This can be used to lift a function into a context so we can apply it to applicatives. As above, liftA is defined as liftA f a = pure f <*> a, which is equivalent to writing fmap f a. This gives our first applicative property. There’s a good description of all the applicative laws in the Haskell Wikibook, but as a quick summary:

• fmap law: pure f <*> x = fmap f x
• Identity: pure id <*> v = v
• Composition: pure (.) <*> u <*> v *<> w = u <*> (v <*> w)
• Interchange: u <*> pure y = pure ($ y) <*> u
• Homomorphism: pure f <*> pure x = pure (f x)

Summary

Applicative functors are functors that support some additional behaviours. While the motivation for functors is to be able to apply a function within a context, the motivation for applicatives is to apply functions with multiple arguments within a context.

We can apply each argument using the <*> operator, giving us expressions like f <$> arg0 <*> arg1 <*> ... <*> argN. We can also lift functions of 1 to 3 arguments using liftA, liftA2 or liftA3.

We saw previously that functors can be quite useful to reuse functions in different contexts, such as when performing IO operations that result in particular values. Applicative functors extends the same benefits to functions that take multiple arguments.

Eta reduction

Say we have two functions, f and g, with exactly the same types. Both take one argument of type a and return something of type b. We’ll define f in terms of g:

f :: a -> b
g :: a -> b

f = \a -> g a

In Haskell this this can also be written as:

f a = g a       ... (1)

If f and g are pure functions (deterministic, no side-effects, no state), then we have:

f = g           ... (2)

We’ve just said in (1) that the functions are equal when applied with the same argument, so for all values in type a the functions f and g will be equivalent; we can use them interchangeably. We don’t have to worry about partial application, or currying, or anything else; we can just apply this equivalency.

Removing redundant argument references like this is called eta reduction (also written as η-reduction). Continually reducing in this way can lead to point-free functions once we’ve omitted all redundant argument references.

Applying with multiple arguments

We can apply this same equivalency to our previous example with multiple arguments:

z = \acc x -> const (acc+1) x

-- `z` is of the form:  
--      f x = g x 
-- where:
--      f = z acc
--      g = const (acc+1)

z = \acc -> const (acc+1)

We use currying, partial application, and concepts like function composition to get our functions into the required f x = g x form, but once we’re there we can use η-reduction to drop the explicit reference to the last argument.

Impure functions

Notice that this doesn’t apply for impure functions, as we could have:

int f(int x) { Console.WriteLine(x); return g(x); }
int g(int x) { return x+1; }

In this case we can’t use f and g interchangeably as they behave differently. In a pure functional language like Haskell we don’t have to worry about this; the type system will differentiate functions with side-effects.

1
2
3
4
5
6
7

length xs = foldl' (\acc x -> acc+1) 0 xs
length = foldl' (\acc x -> acc+1) 0            -- `xs` appears on both sides, so can drop it.
length = foldl' (\acc x -> const (acc+1) x) 0  -- `const` ignores 2nd arg, returns 1st.
length = foldl' (\acc -> const (acc+1)) 0      -- Drop `x` from both sides of lambda
length = foldl' (\acc -> const (succ acc)) 0   -- Replace (+1) with built-in `succ` function
length = foldl' (\acc -> (const.succ) acc) 0   -- Function composition rule: (f.g) x = f(g x)
length = foldl' (const.succ) 0                 -- Drop `acc` from both sides of lambda

The topic of this post is the "argument appears on both sides so can drop it" steps. How do we go from passing foldl' a function which takes two explicit arguments (\arg x -> ...) to none? The answer is by using currying, partial function application and function composition, and we can do both of these in C# (albeit not as neatly, as C# is not really built for it).

Standard C#

We can implement the first version of the Haskell length function above using the following C#:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

public A Foldl<A,B>(Func<A,B,A> f, A initial, IEnumerable<B> xs) {
    var acc = initial;
    foreach (var x in xs) {
        acc = f(acc, x);
    }
    return acc;
}

[Test]
public void TestLength0() {
    var xs = new[] {1,2,3,4};

    var length0 = Foldl<int,int>((acc, x) => acc+1, 0, xs);

    Assert.AreEqual(length0, 4);
}

So the Foldl function loops over a list, and accumulates a value based on a function f passed in. To get the length of a list, our f is going to add 1 to our accumulator for each element in the list.

Currying

Our Foldl, much like Haskell’s, takes a function of the form Func<A,B,A>. It takes two arguments, the accumulator acc and the current list item x, and returns a new accumulator value. In Haskell though, functions all take a single argument and return a function that will handle the rest. This is called currying.

To do this in C# we need to convert Func<A,B,A> into Func<A,Func<B,A>>. In other words, rather than taking two arguments and returning a value, our function will take one argument, then return a function which takes the second argument and finally return the required value. We can write an overload of Foldl to support curried functions:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

public static A Foldl<A,B>(Func<A,Func<B,A>> curriedFn, A initial, IEnumerable<B> xs) {
    var acc = initial;
    foreach (var x in xs) {
        var f = curriedFn(acc); // Call with acc to get remainder of function
        acc = f(x);             // Apply last argument to function
    }
    return acc;
}

[Test]
public void TestLength1() {
    var xs = new[] {1,2,3,4};

    var length1 = Foldl<int,int>(acc => (x => acc+1), 0, xs);

    Assert.AreEqual(length1, 4);
}

Now we need to pass this crazy looking acc => (x => acc+1) line to our fold, but we end up with two functions that each take a single argument.

Dropping the reference to x

Let’s go back to using the original Foldl overload that takes a two argument Func<A,B,A>, and introduce a Const function like we did for the Haskell example:

1
2
3
4
5
6
7
8
9
10
11
12

// `const` should actually be `Func<B,A> Const(A a)`, but we're using `int`
// as that's all we need for this example, and it makes the type defs less verbose.
public static Func<int,int> Const(int a) { return b => a; }

[Test]
public void TestLength2() {
    var xs = new[] {1,2,3,4};

    var length2 = Foldl<int,int>((acc,x) => Const(acc+1)(x), 0, xs);

    Assert.AreEqual(length2, 4);
}

The Const function is curried; it takes one argument and returns a new function which takes a second argument, ignores it and returns the original, which is why it is called as Const(acc+1)(x). We could have also written it like this:

(acc,x) => {
    var newFn = Const(acc+1);
    return newFn(x);
}

Sure, doesn’t make too much sense for C#, but when you get it for free in languages like Haskell it can let us do some interesting stuff. Interesting stuff like partial function application.

We’re currently passing a lambda (acc,x) => Const(acc+1)(x), which is of type Func<int,int,int>. What would happen if we didn’t give this function the x argument?

acc => Const(acc+1)

We know our curried Const function returns a Func<int,int>. And we also know that acc is an int. So our lambda acc => Const(acc+1) will be a Func<int, Func<int,int>>. And we have an overload of Foldl that will take a curried function of type Func<A, Func<B,A>>, so maybe we can use that?

1
2
3
4
5
6
7
8

[Test]
public void TestLength3() {
    var xs = new[] {1,2,3,4};

    var length3 = Foldl<int,int>(acc => Const(acc+1), 0, xs);

    Assert.AreEqual(length3, 4);
}

The Const function needs to eventually get two arguments to return a result (e.g. Const(acc+1)(x)), but instead we’re only applying one of the arguments (Const(acc+1)), and passing around the resulting function that is patiently waiting for the second argument before it returns its result. Because it is in this semi-evaluated state, we call this partial function application.

So where does the second argument come from?

1
2
3
4
5
6
7
8

public static A Foldl<A,B>(Func<A,Func<B,A>> curriedFn, A initial, IEnumerable<B> xs) {
    var acc = initial;
    foreach (var x in xs) {     // <--- We get an `x` from the list `xs`
        var f = curriedFn(acc); // <--- Call `curriedFn` with first argument
        acc = f(x);             // <--- Apply `x` as second argument
    }
    return acc;
}

This corresponds to the following step from our original Haskell version:

length = foldl' (\acc x -> const (acc+1) x) 0  -- `const` ignores 2nd arg, returns 1st.
length = foldl' (\acc -> const (acc+1)) 0      -- Drop `x` from both sides of lambda

Matching experiments with intuition

How can we just lose an argument like that? Well, if the function we’re calling is expecting to use a function with two arguments, it’s going to call it with two arguments. If we pass Foldl a curried function that references both arguments and returns a value like acc => (x => acc+1), it will call curriedFn(acc)(x). If instead we pass it a partially-applied function that returns a new function like acc => Const(acc+1), Foldl is still going to call curriedFn(acc)(x), which applies the second argument to the new function.

In Haskell all functions are curried, so regardless of whether we pass a function f as \acc x -> const acc x or \acc -> const acc, we’re still going to call (f a) b and get the same result.

The end result is that for curried functions, if we have a free variable on the end of both sides of an expression, we don’t have to explicitly reference it. We can drop it off the argument list on the left of the expression at the same time as we stop applying it on the right. So for a Haskell function like this:

  z = fn (\x y -> (someFn x) y)          -- y free on left and right of `->`
    = fn (\x -> someFn x)                -- x free on left and right of `->`
    = fn someFn

Finishing up with function composition

The final steps in our Haskell example where to replace acc+1 with a call to succ acc (which does exactly the same thing, but it looks like a normal function compared with (+1)), and then use function composition to remove the remaining arguments in our lambda.

We can do this, again a tad messily, in C# by introducing our own Succ and Compose functions:

1
2
3
4
5
6
7
8
9
10
11
12
13

public static Func<A,C> Compose<A,B,C>(Func<B,C> f, Func<A,B> g) {
    //Function composition rule: (f.g) x = f(g x)
    return x => f(g(x));
}

public static int Succ(int x) { return x+1; }

[Test]
public void TestLength4() {
    var xs = new[] {1,2,3,4};
    var length4 = Foldl<int,int>(acc => Compose<int,int,Func<int,int>>(Const,Succ)(acc), 0, xs);
    Assert.AreEqual(length4, 4);
}

Ugh, C#’s type inference doesn’t quite go far enough to help us with that awful generic signature, but we’ve now replaced a acc => Const(Succ(acc)) function with acc => Compose<...>(Const,Succ)(acc). And now we’ve got the acc argument free on both sides, so we can drop it:

[Test]
public void TestLength4() {
    var xs = new[] {1,2,3,4};
    var length5 = Foldl<int,int>(Compose<int,int,Func<int,int>>(Const,Succ), 0, xs);
    Assert.AreEqual(length4, 4);
}

Conclusion

We’ve seen that when passing curried functions, if an argument appears at the end of the function’s argument list and it is applied unchanged at the end of the function definition, we can drop it off both and pass around the partially applied function. So:

acc => (x => Const(acc+1)(x))

Is the same as:

acc => Const(acc+1)

This stuff doesn’t translate all that well to C#, but for languages like Haskell where all functions are curried we get equivalences like this:

f = \acc x => const (acc+1) x
  = \acc => const (acc+1)
  = \acc => const (succ acc)
  = \acc => (const . succ) acc
  = const . succ

Hopefully this will help if you’ve found playing around with higher order functions in Haskell as challenging as I have. If you’ve got any questions or if I’ve got anything muddled up please let me know in the comments.

For this post we’ll be working through implementing our own version of the length function, which takes a list and returns a integer reflecting the length of that list.

We’ll start with this non-functioning implementation, which we’ll call length' so it doesn’t collide with Haskell’s built-in function (' is a legal character to have in Haskell identifiers):

length' :: [a] -> Int
length' = error "todo"

To run our function, save it in length.hs, and run ghci length.hs to load it into GHCi, the Haskell REPL. If you update the file, run :r to reload it. See "Loading a Haskell file" in my Haskell quickstart for more information on setting this up.

If we run this with GHCi we get:

ghci> length' [1,2,3]
*** Exception: todo

Great, let’s get started.

Type signatures

The first line is the type signature of our function. The :: means "has type"¹. To the right of :: are the function argument types, and the return type. In this case we can see that length' takes [a] (a list of a) and returns an Int.

Int is pretty clear, but what’s a? It is a type parameter, which means it can stand in for any type. We don’t mind what kind of type is in the list passed to length', just so long as we get a list. This is analogous to List<T> in C#.

Regardless of whether we have [1,2,3], ["hello", "world"] or the empty list [], we can still work out the length of the list without knowing what type of elements are in it.

Functions with multiple arguments

Our length' function only takes one argument. When we have multiple arguments we separate them with multiple -> operators. One example is the built-in const function. We can implement our own version like this:

const' :: a -> b -> a
const' first second = first

This takes an a and a b as an argument, and returns an a. The type signature gives us a fair idea of what it is doing without reading the implementation: const' takes two arguments, and returns the first one. This is exactly what the implementation does. The left-hand side of the = is the function name and argument names, and the right-hand side is the value that the function will evaluated to.

Notice that the first argument to const' is some type a, while the second is some type b. Again, this means that a and b can be any types, but it also means that they don’t have to have any particular relationship. If the type was a -> a -> a, then all the arguments and the return value would have to be of the same type. By having a and b, we’re saying that while they could both be the same type, they could also vary independently. We could pass an Int and String for example. We’ve also said the return value is an a, so that means it will have to return a value that is the same type as the first argument.

Let’s experiment a little with our const' function:

ghci> const' 42 100
42
ghci> const' "hello" 12
"hello"
ghci> const' 'a' [1,2,3]
'a'

We can see that arguments are separated by spaces when passed to functions. Rather than writing f(x,y,z), we write f x y z.

Pattern matching

Let’s get back to our length' function. To start, let’s consider the length of an empty list [].

length' :: [a] -> Int
length' [] = 0

We’re telling Haskell that when it needs to evaluate an expression length' [], it can replace it with 0.

ghci> length' []
0
ghci> length' [42]
*** Exception: lengthy.hs:2:1-14: Non-exhaustive patterns in function length'

This works fine with the empty list, but Haskell doesn’t know how to evaluate the expression when it has a list that doesn’t match the pattern we gave it (in this case, it fails to match a list with a single element in it). We can make our function handle additional cases by providing other patterns it can match. Haskell will try each pattern, from top to bottom, and evaluate the first one that matches (or raise an exception about non-exhaustive patterns if there is no match).

length' :: [a] -> Int
length' [] = 0
length' [a] = 1
length' [b,a] = 2

ghci> length' [42]
1
ghci> length' [42,24]
2
ghci> length' [42,24,37]
*** Exception: lengthy.hs:(2,1)-(4,17): Non-exhaustive patterns in function length'

This seems to be working, but this approach isn’t exactly going to scale well to all possible inputs. Luckily for us, Haskell can do some more advanced matching based on the structure of the data type being passed to the function.

The list type

The list data type we’re using is made up of two different types of values. [a] can either be the empty list [], or be an element joined to the front of a [a] using a :, or cons operator (for construct I think). Its definition would probably look a bit like this (where the | means or).

data [a] = [] | a : [a]

At first this sounds a bit strange: a list is either empty or an element and a list? But if we step through it, it actually makes a lot of sense. [] is a valid list, so 1:[] is also a valid list (an element cons’d on to another list). Which means we could also do 2:(1:[]), and 3:(2:(1:[])), and so on. This is a recursive definition; a list is defined by an element cons’d on to a list. The recursion terminates when we get to the empty list [].

We now know enough to be able to specify all the patterns we need for our length' function. Our input list will either be [], or in the form a : [a]. Together these two patterns cover every list that can be passed to our function (in other words, they exhaustively cover all the inputs).

The first element in the pattern a : [a] is called the head of the list, while the second is called the tail (i.e. the rest). We can think of list [1,2,3] as 1:[2,3] (or 1:(2:(3:[]))). In this case 1 is the head, and [2,3] is the tail. We can also have 3:[], so 3 is the head, and the empty list [] is the tail.

Recursion

So how do we put our knowledge of lists together to work out the length of a list. We saw that lists themselves are defined recursively (a list is defined in terms of itself), and we can use that same approach to define a list’s length.

Let’s take another look at our current version of length':

length' :: [a] -> Int
length' [] = 0
length' [a] = 1
length' [b,a] = 2

We can rewrite the last line in the head / tail pattern:

length' (b:[a]) = 2

The second last line says that length' [a] = 1, so combining those two lines gives us:

length' (b:[a]) = 1 + length' [a]

Here we’ve defined the length of a two element list as one plus the length of a one element list. We can generalise this to any list: the length of a list is one plus the length of the tail of the list. Using this fact, we can finally get a working version of our function:

length' :: [a] -> Int
length' [] = 0
length' (head:tail) = 1 + length' tail

Let’s trace through an example:

length' [1,2,3]
  = length' 1:[2,3]
  = 1 + length' 2:[3]
  = 1 + 1 + length' 3:[]
  = 1 + 1 + 1 + length' []
  = 1 + 1 + 1 + 0
  = 3

Our length' function keeps calling itself until it gets to length' [], which equals 0. This is called the stopping case (also known as the base or terminating case), which does not make any further recursive calls and so causes the chain of function calls stop. And now we can handle all kinds of lists:

ghci> length' []
0
ghci> length' [1,2,3,4,5]
5
ghci> length' [1..2001]
2001

The end of the beginning

The current version of our function is fine, and we’d be quite entitled to stop here. But we can take this example quite a bit further to help us understand more about Haskell, and also to give us a glimpse into more idiomatic Haskell style. I think I’m right in saying that it would be quite rare for an experienced Haskeller to write a function like this (I’m a novice still, so I can’t say for sure). So let’s press on!

Folds

The recursive pattern we’ve defined for length' crops up all over the place when dealing with lists. It’s so common that this way of traversing a list has been abstracted into dedicated functions, called folds. Folds reduce the amount of code we need to write, have mathematical properties that can help us prove things about our code, and provide instantly recognisable patterns of recursion. At first I found folds much harder to read than the equivalent explicit recursive code, but after a bit of practice I find them as least as clear as their explicit or imperative equivalents, and generally prefer them to long-hand recursion.

To work out the length of our list we’re going to have to traverse every element in our list, which means our function is never going to work on an infinite list. This is a clue that we want a left fold (to work on infinite lists we have to use a right fold. For everything else we’ll pretty much use a left fold).

I’ve cataloged my attempts to understand folds in excruciating detail, so take a look at that if you’re keen to see how explicit recursion translates to folds, but for now let’s write an imperative version of left fold using C# to illustrate how it works:

1
2
3
4
5
6
7
8
9
10
11

public static TResult FoldLeft<TItem, TResult>(
    Func<TResult, TItem, TResult> combine,
    TResult initialValue,
    IEnumerable<TItem> items)
{
    var accumulator = initialValue;
    foreach (var item in items) {
        accumulator = combine(accumulator, item);
    }
    return accumulator;
}

The first argument is itself a function that combines a list item with the value accumulated during the previous calls. The second argument gives the case for the empty list (the stopping case for the recursion). Finally, we return the accumulated result.

Here’s our rewritten function:

import Data.List

length' :: [a] -> Int
length' list = foldl' onePlusLengthOfTail 0 list
    where onePlusLengthOfTail tailLength listElement = 1 + tailLength

Despite looking completely different, this works exactly the same as our previous length' function. Let’s look at some key features.

First, we’ve added import Data.List so that we can use the foldl' (fold left) function.² We’ll omit this line from later code samples, but be aware when you see foldl' you’ll need to have the correct import in the source file.

Next, we now only need the one input pattern, as our fold will take care of the empty list case and the head/tail recursion stuff. The empty list case returns 0, and you can see that is the second parameter to foldl'.

We’re also using a where clause. This defines a function called onePlusLengthOfTail, but it can only be called from our length' function. It is like a little private function for the sole use of its parent function. onePlusLengthOfTail combines a list element with the accumulated result of the recursion. In this case we’re saying that for each list element we want to add one plus whatever the result was of recursively calling the previous calls, which is exactly what our previous implementation did.

Lambdas

Pulling out helper functions like onePlusLengthOfTail is often helpful, but in some cases it adds little but noise. Often with Haskell the types will often tell us more information than names do, so once we’re familiar with the fold syntax naming the combining function will typically give us little benefit.

Instead, we can include the function in-line using lambda notation. Haskell’s syntax for lambdas is quite similar to C#’s. In C# we’d write x => x + 1, in Haskell \x -> x + 1.

length' :: [a] -> Int
length' list = foldl' (\acc x -> 1+acc) 0 list

The \ symbol was chosen for its slight resemblance to the lambda symbol ‘λ’. After that are the function arguments, which I’ve called acc for accumulator (it is the accumulated value of our recursion) and x for whatever list element we’re looking at. Now we don’t actually use the value of x, so Haskellers would generally replace it with an underscore like this: \acc _ -> 1+acc. This isn’t actually an argument name, it is Haskell’s symbol for a catch-all pattern. It will match anything, a bit like the * wildcard character typically used for searches.

Partial function application

Remember our const' function which takes two arguments, ignores the second and returns the first? What happens when we call it with one argument?

Let’s use GHCi’s :t command to check it’s type:

ghci> :t const'
const' :: a -> b -> a
ghci> :t const' 'a'
const' 'a' :: b -> Char

Normally const' is type a -> b -> a, but const' 'a' is type b -> Char. What’s going on?

Well, all functions in Haskell are curried, which means they only take one argument, and return a function that takes the rest. So the real type of const' is actually a -> (b -> a); it takes an a and returns a function which takes a b and returns an a. Because of the associativity of the -> operator and of function application, we can write it either way. This also means we can call Haskell functions with as many or as few of the required arguments as we like, and we’ll get back a function to finish the job as soon as we provide the remainder of the arguments.

This is known as partial application. We can partially apply the arguments to a function to get back another function. Once all the arguments have been passed in we’ll get the final value.

The best example I can think of to illustrate this is the (+) function. Normally this would take 2 arguments (such as 4 + 1, or (+) 4 1, both are legal in Haskell. The former is called infix position, and the latter is function notation.) Let’s just apply one argument to (+):

ghci> let addOne = (1+)
ghci> :t addOne
addOne :: Integer -> Integer
ghci> addOne 4
5
ghci> addOne 72
73

Here we’ve partially applied the argument 1 to (+), which has returned a function that takes the next argument and returns the result. We can then call addOne as a single argument function.

Back on topic please Dave!

But we are still on topic! Look at our length' function:

length' :: [a] -> Int
length' list = foldl' (\acc _ -> 1+acc) 0 list

It takes a [a] and returns an Int. Now the foldl' on the right hand side takes a function, an Int and a [a] and returns an Int. If we think back to partial application, that means that foldl' (\acc _ -> 1+acc) takes an Int and a [a] and returns an Int. Which means that foldl' (\acc _ -> 1+acc) 0 takes a [a] and returns an Int.

Hold on, read the last sentence again! Both length' and foldl' (\acc _ -> 1+acc) 0 are of type [a] -> Int. So really:

length' = foldl' (\acc _ -> 1+acc) 0 

We don’t need to explicitly add the list argument, as foldl' (\acc _ -> 1+acc) 0 is going to return a function which takes a list anyway. Just as we were able to write let addOne = (1+), we can assign the name length' to foldl' (\acc _ -> 1+acc) 0.

The general rule is whenever an argument appears on the end of both the left and right hand sides of our function definition, we can drop it off thanks to partial application. (The one catch is when the last argument is surrounded by parentheses such as f (g x). We need to change that a little before we can drop off the x. We’ll see how to do that shortly.)

This may initially seem a little pointless, but we’ll rarely see Haskell code that keeps an unrequired argument on both sides so it is a good idea to get familiar with it. Once we get comfortable with partial application keeping the arguments just appears wasteful, and will stick out like a sore thumb.

Point free

Not explicitly referencing arguments is called point-free style. While the particular case mentioned above (dropping an argument referenced on both sides of a function definition) is pretty essential for idiomatic Haskell, there is a little more debate over point-free style, where every effort is made to not reference any arguments at all. (Hence why it is also known, mainly jokingly, as "point-less" style :).)

Much like folds, I initially couldn’t see why anyone would want to write in point-free style as it seems to make code so much more difficult to read. Again, after a little time adjusting to it, I found that I could start to read it quite naturally, with the added benefit of being concise, and making the all-important composition and chaining of functions much neater. That said, I’d guess that even the most ardent point-free fans would acknowledge that there are some cases where having explicit arguments is clearer, so the aim is not to dogmatically pursue point-free functions, but to keep an eye out for where heading in that direction will help our code. Love it or hate it, I’d suggest getting comfortable with reading point-free style as you’ll see lots of Haskell code written like this, and it is one of those things you need to give yourself a chance to get used to.

To move a bit closer to a point-free function, let’s get rid of the reference to the unused second argument of our lambda.

(\acc _ -> 1+acc)

This is a function which takes an Int and an a, ignores that a and returns a new Int. Ignores the second argument huh? That sounds a lot like our const' function:

(\acc x -> const' (1+acc) x)

We’ve had to put the x back in for now so we can reference it on the right hand side of our function definition, but now we have the x as the last argument on both sides. And from our work with partial application we know that means we can drop it:

(\acc -> const' (1+acc))

Now we’re partially applying one argument to const', so it will return a function which takes another argument, ignores it and return the first argument it was initially called with (1+acc).

length' :: [a] -> Int
length' = foldl' (\acc -> const' (1+acc)) 0 

Function composition

Function composition is a way of combining functions that each take one argument. Say we have two functions, f :: b -> c and g :: a -> b. We can compose f and g such that:

(f . g) x = f (g x)

The (.) operator means composition. Notice that g x returns a b, and f takes a b and returns a c. So f . g :: a -> c. Again, initially confusing, ultimately awesome. Composition means we can wire up lovely pipelines of functions that values flow through, without the traditional imperative steps of call this, assign to that, call another, assign to new variable and so on.

Now we’ve now got this little const' (1+acc) expression which is just pleading with us to use function composition, but it’s a little hard to see at the moment. It would be clearer if we used our addOne function from earlier. Remember we wrote let addOne = (1+)? Well in Haskell this function already exists, and is called succ for successor.

const' (succ acc)

This is now in the form f (g x), where f = const' and g = succ. So substituting in for f . g:

length' :: [a] -> Int
length' = foldl' (\acc -> (const' . succ) acc) 0 

And look what’s appeared on both sides of our lambda: \acc -> (const' . succ) acc. Thanks to partial application we can drop off the acc argument and we have:

length' :: [a] -> Int
length' = foldl' (const' . succ) 0 

It’s small, it’s beautiful, it actually works, and if you’re just starting out it’s probably utterly incomprehensible. Give it a little while though. With a bit of practice it’ll be second nature to you in next to no time. (I didn’t believe this either, but after a couple of months I’ve been suitably warped by the small amount of functional programming I’ve done that I’m actually starting to prefer this. :))

Wat?

While we’re waiting for our brains to warp enough to be able to read this fluently, let’s look at some quick tips to help us decipher it.

First, we have our function name length' and the type signature. It takes a list of a and returns an Int. It’s a pretty safe bet that it is intended to return the length of a list.

Next, we can see it’s using a fold, which means it is recursing over the list. It has a 0 as the second parameter to the fold, so that means when given the empty list the length will be 0.

Now we have this strange point-free function passed to foldl'. I find it easiest to read composed functions is to go from right to left. Our composed function will call succ on an argument (add one to it), and call const' on the result, which will take two arguments but ignore the second. So we’re adding one to the first argument passed in. (Another approach is to translate back to acc -> const' (succ acc), and take as many steps reversing the process we went through to get to the point it becomes clear.)

Finally, we know (or can look up via Hoogle or using :t in GHCi) that foldl' calls the const'.succ function with first the accumulated value of the fold, and the current list item. So we’re going to start with our base case of 0, and for each list item we’re going to add 1 to it. Which will give us the length of the list.

Learning cliff

I found these topics quite confusing when I first encountered them. If you’re feeling similarly, it’s worth keeping in mind that most of us have been trained to think of programming imperatively rather than functionally, so it is naturally going to take some time to adjust to ideas like reducing expressions, folds, function composition and point-free style. I really believe it is worth persisting with. Even if you don’t end up using it regularly, it is worth it to get a different way of looking at programming problems.

Conclusion

In this post we’ve seen some of the basics of Haskell’s type system and function syntax, and applied pattern matching on lists and recursion to implement our own length' function.

We’ve then seen how to replace the explicit recursion code with a fold, before applying partial application and function composition to make the code very concise.

These techniques are very powerful (more so than this simple example suggests), and by learning to use them we can get real, safe reuse of code by partially applying and composing small, very cohesive functions in a myriad of ways. Even in this small example we used foldl', const and succ; we wrote almost no code, and instead just wired together existing pieces. Coupling to something as fundamental as "adding one" is a much safer kind of reuse than I’m used to being bitten with in other programming paradigms.

I hope you enjoyed this post. As you can probably tell, I’m really enjoying learning a different perspective on programming, and I hope I’ve managed to pass some of that along. Please let me know any parts are unclear so I can try and improve them.

Types containing values

Many types can be thought of as holding values. For example, lists and arrays can hold integers, strings or other types of values. In .NET, we have the Nullable<T> type, which can hold null, or a value of type T. In Haskell there’s the Maybe a type, which similarly can hold Nothing or an a. We can even think of commands or partially evaluated functions as holding values: once they finish executing they’ll have or return a particular value.

For now, let’s just think of these types as boxes or containers that can hold values of some type.

Mapping over boxes of values

Say we have a function fn which can take some value of type a and return a value of type b. In Haskell we express this as fn :: a -> b, or as Func<A,B> fn in C#.

Now imagine we have some sort of box that can hold some quantity of a. We’d like to apply fn to the a we have in the box, and get a new box of b. But fn works on an a, not on a "box of a", so we need a way of apply our fn inside the box, and then a way of shoving the resulting b into a new box.

The solution is to define a function called fmap which does exactly that. It takes a function (a -> b), and a box of a, and returns a box of b:

-- Pseudo-Haskell
fmap :: (a -> b) -> boxOf a -> boxOf b

// Pseudo-C#
Box<B> Fmap<A,B>(Func<A,B> fn, Box<A> boxOfA);

Defining fmap

Now we’ve previously mentioned that these boxes can actually be different types (lists, Maybes or Nullable<T>s). How does fmap know how to unpack and repack all the different types of boxes?

To be able to do this, each type of box needs its own implementation of fmap. Boxes that have a valid fmap defined for them are called functors. Haskell has a lot of these built-in, but we could also define them ourselves:

1
2
3
4
5
6

-- For lists:
fmap fn list = map list

-- For Maybe, which can be either Nothing or (Just someValue)
fmap fn Nothing = Nothing
fmap fn (Just someValue) = Just (fn someValue)

Notice that fmap for a list is exactly the same as normal map. In other words, we iterate over each value in the list, apply the function to each, and then return the new list. For Maybe, mapping the function over Nothing returns Nothing. Mapping over an instance that holds a value gets that value, applies the function to it, and returns a new instance of Just the result.

C#’s type system doesn’t support all the features we need to get a lot of use out of functors, but we can still get an idea of how fmap might look for enumerables and nullables:

1
2
3
4
5
6
7

public static IEnumerable<B> fmap<A,B>(Func<A, B> fn, IEnumerable<A> functor) {
    return functor.Select(fn);
}

public static B? fmap<A, B>(Func<A, B> fn, A? functor) where A : struct where B : struct {
    return functor == null ? null : (B?) fn(functor.Value);
}

Graduating from boxes

Notice that fmap preserves the type of box used. For example, if we call fmap on a list, we’ll get another list back. If we call fmap on a Maybe, we’ll get another Maybe back. We never call it with a list and get a Maybe back. If we call our box f, then calling fmap on f a will give us back an f b. The f is preserved.

Rather than using the box analogy, the type f is often referred to as the context, so f a is an a value in the context of f. An a in a context where there maybe be 0 or more values is a list of a. Maybe is a context that may have zero or one a. fmap maps a function from a to b, preserving the context.

Lifting functions is useful

Haskell (and I assume most functional programming languages) has some really interesting ways of putting types together. It is quite common to have simple data types (like integers, strings etc) and functions that operate on them. We can also have more complex data types that can work over many types (they are polymorphic), such as lists of a or Maybe a (where a can be an integer, string, function or even another type of list). Because this polymorphism is so common, it would be nice to be able to reuse functions that work on simple types in different contexts, and that’s exactly what functors let us do.

This is known as lifting a function; transforming a function like a -> b to work in another context, like f a -> f b.

For example, we can use lift a standard integer operation like (+1) to work on Maybe Int:

ghci> fmap (+1) (Just 10)
Just 11
ghci> fmap (+1) Nothing
Nothing

Or apply a standard string function to a Maybe String:

ghci> fmap reverse (Just "hello world!")
Just "!dlrow olleh"
ghci> fmap reverse Nothing
Nothing

And then of course there is the familiar mapping over a list (as mentioned earlier, map, or Select in .NET, is just fmap for list):

ghci> fmap (*2) [1..10]
[2,4,6,8,10,12,14,16,18,20]

csharp> new[] {1,2,3,4,5,6,7,8,9,10}.Select(x => x*2);
{ 2, 4, 6, 8, 10, 12, 14, 16, 18, 20 }

As a pure functional language, Haskell eschews code with side-effects, which includes some innocuous-sounding things like reading or writing to files. To work within this restriction, side-effects can be wrapped up in types like IO a. Because IO is a functor, we can use fmap to work with the value inside the IO context without having to explicitly pull out the value (so side-effects stay neatly wrapped up in their IO box). Say we wanted to read an integer from STDIN, here’s how it would work with and without fmap:

1
2
3
4
5
6
7

doubleInput = do
    input <- getLine
    let enteredNumber = read input :: Int   -- read string as int
    let double = 2 * enteredNumber          -- (2*)
    return $ show double                    -- show int as string

doubleInputWithFmap = fmap (show . (2*). read) getLine

Finally, functors are just one part of a large hierarchy of type classes. Other type classes like applicative functors and monads build on the properties of functors to provide their own interesting capabilities.

Well-behaved functors

We’ve seen that functors are types that can can have functions mapped over them, thanks to an corresponding implementation of fmap. That’s the bulk of it, but there are also two formal properties that these fmap implementations need to have in order for a type to act as a functor.

The first is that mapping the identity function over a functor is the same as calling the identity function directly on the functor. id is the identity function in Haskell, the C# equivalent being x => x. The identity function takes an argument and returns it, unchanged.

fmap id a = id a

-- Example
ghci> id (Just 42)
Just 42
ghci> fmap id (Just 42)
Just 42

The second is that composing two functions then mapping them needs to give the same result as mapping each function in turn. In other words:

fmap (f . g) = fmap f . fmap g

Typeclassopedia’s entry on functor laws mentions that satisfying the first law automatically satisfies the second. Which is good, because to me the first is a lot easier to follow. :)

These properties aren’t enforced by the type system, but we need to make sure our functors have them or else our functor won’t behave like all the other nice functors. These properties guarantee that fmap preserves the structure (or context) of our functor.

References

• "Functors, Applicative Functors and Monoids", Learn You A Haskell
• "Functor", Wikipedia
• "Map (higher-order function)", Wikipedia
• "Typeclassopedia", HaskellWiki
• "Applicative functors", Haskell Wikibook

Whenever I find myself evaluating different design patterns or counting responsibilities to work out where the feature should go or which areas I should refactor, I stop and work out the minimum amount of code I’d need to write to solve the problem, ignoring design considerations. Once I’ve starting thinking about the problem in that light, working out where to put that code becomes a bit easier. If the code violates my sense of design aesthetics, it could just be because it is a messy problem, and no matter how hard I try to abstract or design my way out, the fundamental messiness still remains.

As an example, say we’re working with a library that misuses exceptions, throwing for genuine exceptional cases, and also as a way to notify callers of a change in mode. I might find myself getting grand ideas like anti-corruption layers, Command patterns with reused error handling, or trying various continuation ideas. If there’s a lot of existing code I might start getting bogged down in working out all the classes I’m going to have to change to fit in with this new error handling infrastructure. These kind of premature generalisations are a sure sign I need to stop and simplify.

If we think about the problem for the moment, at a minimum we’re going to need a try .. catch somewhere, and chances are we’re going to have to do something disgusting like swallow the irrelevant exceptions. We’re now in a position to think about exactly where this responsibility should go based on our standard design rules. In this case, it may be best to deal with this immediately at the boundary between our code and the library, rather than creating a more formal abstraction for handling them (or not, the point is that we know the code and minimum mess required, so we are in a better position to work out where to put it).

TDD can be a useful way to do a similar thing; writing a test that uncovers the minimum increment of code required. Sometimes though it’s not clear from what class or in which direction you should drive the code, in which case I’ve found thinking in terms of the minimum amount of code required then spiking some options around that a helpful alternative.

So next time you’re pondering whether to toggle a UI element’s visibility using MVVM or an MVP-variant for UI separation, or whether to push the conditional in to a Strategy implementation, just remember that somewhere along the line an evil if statement or similar is going to have to execute and switch the element’s visibility switched from "visible" to "hidden".

Solving algebraically

The signature for $map$ is:

$$map::(a\to b)\to [a]\to [b]$$

The first argument is a function which takes an $a$ and returns a $b$. The second argument is a list of $a$. The last type, a list of $b$, is the function’s return value.

To work out the signature of $mapmap$, we need to substitute in what we know about $map$’s type signature to work out the resulting combination of $a$ and $b$. I found this really tricky, but by applying a few rules we can work it out.

First, let’s pass some arbitrary function $f::c\to d$ as the first argument to $map$.

$$map::(a\to b)\to [a]\to [b]$$ $$f::c\to d$$ $$mapf::[c]\to [d]$$

In our case, we want to pass $map$ as $f$. But $f$ is a function that takes one argument, while $map$ takes two. So how can we use it in place of $f$? Well, the $\to$ operator is right-associative, which means we can re-write $map$ like this:

$$map::(a\to b)\to ([a]\to [b])$$

This is know as currying. In Haskell, all functions can be considered to take one argument, and return a function that takes the remainder of the arguments. Here, we’re thinking of $map$ as a function which takes a function from $a\to b$, and returns a function that takes a $[a]$ and returns a $[b]$.

Now we have $map$ in a form that matches $f::c\to d$:

$$f::c\to d$$ $$map::(a\to b)\to ([a]\to [b])$$

So: $$c::(a\to b)$$ $$d::([a]\to [b])$$

Now we can substitute back into our $mapf$ type declaration:

$$mapf::[c]\to [d]$$ $$mapmap::[(a\to b)]\to [([a]\to [b])]$$ $$mapmap::[a\to b]\to [[a]\to [b]]$$

So $mapmap$ takes a list of functions of the form $(a\to b)$ and returns a list of functions that take $[a]$ an returns $[b]$ (i.e. $([a]\to [b])$).

Solving intuitively

The other suggested approach was to think about the abstractions being used, rather than the mathematical basis for the functions. I tend to struggle with this, but it is worth trying to come to grips with the concepts and intention, and not just rely on somewhat-blindly applying maths principles.

The $map$ function conceptually represents transforming a function to work on a list. For example, (+1) adds one to a single number, while map (+1) adds on to a list of numbers. This corresponds to the step in our last approach where we starting thinking of $map$ as $map::(a\to b)\to ([a]\to [b])$.

Continuing this line of thinking, $mapmap$ will then take a list of functions $[a\to b]$ and return a list of transformed functions that work on lists of $a$, or $[[a]\to [b]]$. This gives us the same result as last time, $mapmap::[a\to b]\to [[a]\to [b]]$.

I tend to get lost when I try to think about it this way, but hopefully I’ll start to get the hang of reasoning about functions this way as I get more practice. If not, there is always the option of falling back on the maths.

Associativity property

Associativity is a property of some binary operators that means the order operators are evaluated does not matter. An operator $\oplus$ is associative if:

$$(x\oplus y)\oplus z=x\oplus (y\oplus z)$$

A familiar example is addition. We can safely write $1+2+3$ and know we’ll get the correct answer irrespective of the order in which it is evaluated, as $(1+2)+3=1+(2+3)$. An example of a non-associative operator is subtraction, as $(1-2)-3\ne 1-(2-3)$.

Two operators are said to associate if they can be evaluated in any order:

$$(x\oplus y)\otimes z=x\oplus (y\otimes z)$$

Operator associativity

Related to this mathematical property is operator associativity or fixity, which is essentially an exercise in parenthesis-saving. For non-associative operations where order of evaluation matters, we can define the operator as left-associative or right-associative depending on how we want it to evaluate in the absence of parentheses.

For a left-associative operator:

$$x\oplus y\oplus z=(x\oplus y)\oplus z$$

For a right-associative operator:

$$x\otimes y\otimes z=x\otimes (y\otimes z)$$

Applying to programming

In terms of functional programming, a binary operator is a two argument function. We tend to refer to operators as functions used in infix position, or between arguments like a `f` b, as opposed to function notation, which is the more familiar f a b arrangement. A function can be associative regardless of the notation used. Our previous $1+2+3$ example could be rewritten in function notation as (+) ((+) 1 2) 3 = (+) 1 ((+) 2 3).

Monoids

Associative functions seem useful for reasoning about folds, particularly when part of a monoid. A monoid is formed by an associative binary function and an identity element $a$ that exists such that: $$\begin{array}{c}\hfill x\oplus a=x=a\oplus x\end{array}$$

Addition is a monoid for integers, as it is associative and has $0$ as an identity value.

$$(x+y)+z=x+(y+z)$$ $$x+0=x=0+x$$

When an operator $\oplus$ and value $a$ form a monoid this can simplify how we think about folds, as:

$$foldr\oplus a[]=a$$ $$foldr\oplus a[x_0,x_1,...,x_n]=x_0\oplus x_1\oplus ...\oplus x_n$$

Monoids also give us the first duality theorem: for monoids and a finite list $xs$, $foldr\oplus axs=foldl\oplus axs$. This equivalency means we can decide on which fold to use based purely on efficiency when working with monoids and finite lists.

There seems to be much more to monoids in Haskell, but the point I’m trying to make is that associativity forms the basis for some more advanced and quite useful concepts (functors being another example).

Reducing noise

For maths and programming I’ve always erred on the side of over-specifying parentheses, but as I get more into functional programming I’ve found learning operator associativity starts to really reduce the noise. One example is function composition using the (.) operator. Because this is an associative operation, we can compose a string of functions without the noise of parentheses: f . g . h.

Currying

Another important example of noise-reduction is the behaviour of type-mapping operator $\to$. Type-mapping is right-associative, which means that $f::a\to b\to c$ is actually equivalent to $f::a\to (b\to c)$. This is also known as currying. Let’s take good old integer addition as an example again. Its type is:

$$+::Integer\to Integer\to Integer$$

Normally we’d call this with two arguments such as 1+2 and get an integer 3 back. But $+$’s type signature can also be expressed as:

$$+::Integer\to (Integer\to Integer)$$

This means $+$ can take an integer, and return a function which takes an integer and returns the final result. So in Haskell we can do things like this:

*Main> :type (+)
(+) :: Num a => a -> a -> a
*Main> let addOne = (1+)
*Main> :type addOne
addOne :: Integer -> Integer
*Main> addOne 2
3

Here we’ve given (+) just one argument, and the result is an addOne function that will take a single integer and add one to it. The right-associativity of type mapping, combined with the left-associativity of function application, gives us standard calling semantics for the type declaration a -> a -> a, while also letting us partially apply functions as a -> (a -> a). In fact, all Haskell functions are curried (they only take one argument, and return a function to handle the rest), but thanks to operator associativity we can call them in whichever way makes sense for each situation.

Bird and Wadler describe a strict function as one that is undefined when its input is undefined. The ⊥ symbol, or bottom, is used to represent ‘undefined’, so f is strict if f ⊥ = ⊥, otherwise it is non-strict.

I interpret this to mean that if a function can take an undefined or generally awkward expression (like undefined, 1/0 or an infinite list) for one of its arguments and return a defined, sensible value then it is non-strict in that argument.

The first example they give for this is a function that returns a constant:

three :: a -> Int
three x = 3
{- Haskell GHCi session:
    *Main> three 3
    3
    *Main> three "hello"
    3
    *Main> three undefined
    3
    *Main> three (1/0)
    3
    *Main> three [1..]
    3
-}

We can see that three ⊥ = 3, so it is non-strict. It never actually needs to evaluate its argument. So we can give it all kinds of wonderful arguments likethree (1/0) (divide by zero), three [1..] (infinite list), three (head []) (the first element of an empty list) or even three undefined, and it will still happily return 3.

Perhaps a more familiar example is ||, the boolean or operator. It will only evaluate its second argument if the first is False:

*Main> True || False
True
*Main> False || True
True
*Main> False || False
False
*Main> undefined || True
*** Exception: Prelude.undefined
*Main> True || undefined
True
*Main> False || undefined
*** Exception: Prelude.undefined

Here ⊥ || x = ⊥, so || is strict in its first argument. But we also have True || ⊥ = True, so || is non-strict in its second argument when its first is True. This is how || is implemented in many languages (including C#, Ruby et al.), not just for functional languages like Haskell.

Non-strictness and laziness

Let’s have a look at the related concept of laziness. Functional languages work by reducing expressions to their simplest forms (called canonical or normal form). There can be several approaches to doing this. Earlier we saw that Haskell could happily evaluate three (1/0), even though dividing by zero isn’t generally a good idea. This was because Haskell chose to reduce this expression by first applying the definition of the function three; that is, three with any argument reduces to the value 3.

A language could also decide to reduce the argument first. This would mean applying the rule of the division operation (/) first, then trying to apply the definition of 3.

The first strategy is known as lazy-evaluation, while the second is the eager-evaluation us imperative folks are more familiar with. Imperative languages tend to evaluate arguments before calling a function, so trying to call Three(SomeMethodThatThrows()) in C# will break where a non-strict, lazy language like Haskell doesn’t.

As far as I can tell, non-strictness is the mathematical property we saw at the beginning of this post, while lazy-evaluation is the expression reduction strategy some languages like Haskell use to implement non-strictness.

References

• Richard Bird and Philip Wadler, Introduction to Functional Programming.
• Wikibooks, Haskell/Laziness. Online, accessed 2012-03-30.
• Haskell.org, Lazy vs. non-strict. Online, accessed 2012-03-30.

In part 1 we found that a fold is a way of abstracting recursive operations over lists. In part 2 we saw that we could also express loops using recursion, which we could extract into a different type of fold. We learned that the loop-like fold is called a left fold (it accumulates its values on the left of the expression), and that our original fold was called a right fold (which accumulates to the right).

1
2
3
4
5
6
7

foldLeft :: (a -> b -> a) -> a -> [b] -> a
foldLeft f acc (head:tail) = foldLeft f (f acc head) tail
foldLeft _ seed [] = seed

foldRight :: (a -> b -> b) -> b -> [a] -> b
foldRight f acc (head:tail) = f head (foldRight f acc tail)
foldRight _ seed [] = seed

We saw we could implement several functions using both left and right folds (like sum, length, and mapFn). As both folds abstract away explicit recursion, they seem capable of producing the same results, just with different orders of evaluation. It turns out these differences in evaluation have some important implications, so in this post we’ll take a closer look at them.

Flipped arguments and evaluation order

Both our folds take as arguments a function, a seed/accumulator, and a list. If we look closely at the type definitions of each, we can see that the first arguments differ:

foldLeft :: (a -> b -> a) -> a -> [b] -> a
foldRight :: (a -> b -> b) -> b -> [a] -> b

The function passed to foldLeft is called with the accumulator, then an item from the list (f acc head), but foldRight is called with the list item then the accumulator (f head acc). The function arguments are flipped. This can make some folds easier to write in one form than the other. In particular, folds that create lists seem to more naturally fit with foldRight:

addOneRight list = foldRight (\head acc -> (head+1):acc) [] list

Here we add one to the list head, then prepend that onto the accumulated list using (:) (called cons, used for constructing lists).

If we try and write this using a left fold, the order of the list head and accumulated list arguments passed to our lambda function gets flipped:

addOneLeft' list = foldLeft (\acc head -> (head+1):acc) [] list

If we run these examples though, we get quite different results:

*Main> addOneRight [1..5]
[2,3,4,5,6]
*Main> addOneLeft' [1..5]
[6,5,4,3,2]

This is due to the difference in evaluation order we identified between the fold types, although now it starts to have more impact than just where our parentheses end up. foldRight builds up an expression that evaluates from right to left, so our list gets built up like this:

addOneRight [1..5] 
    = (1+1) : (addOneRight [2..5])
    = (1+1) : (2+1) : (addOneRight [3..5])
    = ...
    = (1+1) : (2+1) : (3+1) : (4+1) : (5+1) : []
    = [2,3,4,5,6]

Here our last list item 5 gets evaluated with our accumulator [] first. In other words, it is right-associative; foldRight (+) 0 [1..5] will create the expression 1 + (2 + (3 + (4 + (5 + 0)))) which evaluates the right-most term first.

But foldLeft works more like a loop, and evaluates from left to right (it is left-associative; foldLeft (+) 0 [1..5] creates ((((0 + 1) + 2) + 3) + 4) + 5), so our first list item 1 gets evaluated with the accumulator [] first:

addOneLeft' [1..5]
    = addOneLeft' ((1+1) : []) [2..5]            -- Evals 1 with accumulator [] first.
    = addOneLeft' ((2+1) : (1+1) : []) [3..5]
    = ...
    = (5+1) : (4+1) : (3+1) : (2+1) : (1+1) : []
    = [6,5,4,3,2]

To fix our addOneLeft function, we want to append the item to the end of the accumulated list, rather than add it to the front. We can do this by using (++) which concatenates lists, and use [head+1] to convert the list element to a list so we can concatenate it.

addOneLeft list = foldLeft (\acc head -> acc ++ [head+1]) [] list
{-
addOneLeft [1..5]
    = addOneLeft ([] ++ [1+1]) [2..5]
    = addOneLeft ([] ++ [1+1] ++ [2+1]) [3..5]
    = ...
    = [] ++ [1+1] ++ [2+1] ++ [3+1] ++ [4+1] ++ [5+1]
    = [2,3,4,5,6]
-}

This gives us the [2,3,4,5,6] answer we expect.

So not only do the functions we pass to both folds differ in argument order, but the order the accumulated value is populated is also reversed.

To infinity, and beyond!

In the last section we saw that foldLeft and foldRight evaluate in opposite orders. This difference in evaluation order has another important impact, and that is how the different folds handle infinite lists.

Taking just a bit of an infinite list

First we’ll need to take a small digression to explain how Haskell works with infinite lists. The take function in Haskell grabs a specified number of elements from the start of a list. We can implement a basic version of this function so we can trace exactly what’s happening when we call it.

1
2
3
4

take' :: Num a => a -> [b] -> [b]
take' 0 _ = []              -- The underscore '_' matches any argument value.
take' _ [] = []
take' i (head:tail) = head : (take' (i-1) tail)

We can use our take' function like this:

*Main> take' 0 [1..10]
[]
*Main> take' 5 [1..10]
[1,2,3,4,5]
*Main> take' 3 [1..]
[1,2,3]

The first two calls take 0 and 5 elements respectively from a list of 10 numbers. The third call takes 3 elements from [1..], which is Haskell for “an infinite list starting from 1”. We can get away with using infinite lists because Haskell uses lazy evaluation (more precisely, it is non-strict); it can evaluate only what it absolutely needs to in order to get a result from an expression.

If you type [1..] into GHCi, the interpreter will try and print this list to the terminal. Because printing every element in a list requires evaluating every element, this will continually spit out numbers until you stop it with Ctrl + c or something catastrophic happens to the process (like being stopped by the heat death of the universe).

If, instead of dumping [1..] to the terminal, we use it as an argument to our take' function, it will only evaluate the elements it needs from the list.

take' 3 [1..]
    = 1 : take' 2 [2..]
    = 1 : 2 : take' 1 [3..]
    = 1 : 2 : 3 : take' 0 [4..]
    = 1 : 2 : 3 : []        -- We defined take' 0 of any list as []

Because take' 0 [4..] can return [] without further evaluation of the infinite list [4..], Haskell returns the result without getting stuck in an infinite loop.

Folding over infinite lists

Let’s apply this knowledge to folds. I’ll try adding one to each element of an infinite list using our addOne functions, and only taking the first three elements from the result:

*Main> take' 3 (addOneRight [1..])
[2,3,4]
*Main> take' 3 (addOneLeft [1..])
^CInterrupted.

Hmm. The addOneRight call worked fine, but addOneLeft just hung until I interrupted it using Ctrl + c. We’ve already seen how the addOneRight and addOneLeft functions are evaluated, so let’s trace through how that pattern works with infinite lists.

addOneRight [1..]
    = (1+1) : addOneRight [2..]
    = (1+1) : (2+1) : addOneRight [3..]
    = (1+1) : (2+1) : (3+1) : ...

addOneLeft [1..]
    = addOneLeft ([] ++ [1+1]) [2..]
    = addOneLeft ([] ++ [1+1] ++ [2+1]) [3..]
    = addOneLeft ([] ++ [1+1] ++ [2+1] ++ [3+1] ++ ...) ...

The right fold version is able to evaluate elements straight away; first (1+1), then (2+1) and so on, so take' can start consuming them immediately. The recursive call keeps generating elements off to the right, but if we stop needing to use the next element, Haskell’s going to be lazy and not evaluate the next recursive step.

take' 3 (addOneRight [1..])
    = take' 3 ((1+1) : addOneRight [2..])
    = (1+1) : take' 2 (addOneRight [2..])
    = (1+1) : take' 2 ((2+1) : addOneRight [3..])
    = (1+1) : (2+1) : take' 1 (addOneRight [3..])
    = (1+1) : (2+1) : take' 1 ((3+1) : addOneRight [4..])
    = (1+1) : (2+1) : (3+1) : take' 0 (addOneRight [4..])
    = (1+1) : (2+1) : (3+1) : []        -- take' 0 of any list is [], we don't need to eval it.

In contrast, the left fold version can’t start evaluating until its recursive call reaches the end of the list.

take' 3 (addOneLeft [1..])
    = take' 3 (addOneLeft ([] ++ [1+1]) [2..])
    = take' 3 (addOneLeft ([] ++ [1+1] ++ [2+1]) [3..])
    = take' 3 (addOneLeft ([] ++ [1+1] ++ [2+1] ++ [3+1]) [4..])
    = take' 3 (addOneLeft ([] ++ [1+1] ++ [2+1] ++ [3+1] ++ ...) ...)

So while take' was able to get a list of the form (1+1) : rest from addOneRight that it could start using straight away, the left fold has to completely evaluate addOneLeft before it gets access to a list in that form. And because that requires evaluating a function over every element in an infinite list, that’s going to take quite some time…

Strictly thwarting our conquest of infinity

So far we’ve seen that while left folds aren’t going to do us any favours when it comes to infinite lists, right folds seem to take them in their stride. There is a wrinkle here though; if the function we pass to our right fold needs to evaluate both its arguments (or its right argument first), then the recursion is not going to terminate and we’re going to end up hanging, just like our left fold.

The arguments a function needs to evaluate to produce a result is described as its strictness. A function that always needs to evaluate both its arguments is said to be strict in both its arguments. If it can sometimes get away with only evaluating some of its arguments it is non-strict (or, for example, just strict in its first argument).

An example of a function that is strict in both its arguments is (+), which needs to evaluate both its left and right sides to return a result:

*Main> foldRight (+) 0 [1..10]
55
*Main> foldRight (+) 0 [1..]
^CInterrupted.

While not being able to sum an infinite list does not come as a complete surprise, even code that we imagine could return a result early will not necessarily work. Let’s try and see if the sum of our list exceeds 5:

*Main> (>5) ( foldRight (+) 0 [1..10] )
True
*Main> (>5) ( foldRight (+) 0 [1..] )
^CInterrupted.

Why doesn’t this stop as soon as the sum reaches 20?

(>20) (foldRight (+) 0 [1..])
    = (>5) (1 + foldRight (+) 0 [2..])
    = (>5) (1 + (2 + foldRight (+) 0 [3..]))
    = (>5) (1 + (2 + (3 + foldRight (+) 0 [4..])))
    = ...

Even though our total is now greater than 5, our (+) operator isn’t able to give us a result because it needs to evaluate both its left and right sides. When it looks at (1 + rest), it tries to evaluate rest to give us an answer, which brings it to (1 + (2 + rest)). Again it needs to evaluate rest to finish evaluating the original (1 + rest) call. So before we can check (>5), we have to wait until the infinite number of right-hand sides have been evaluated. And so again we reach for Ctrl + c.

This is different to our take' example which used the (:) and (++) operators, which are non-strict. If a function only needs the head of a list, it can grab that from 1:rest without having to strictly evaluate the rest argument.

Left or right?

So how to we know when to choose a left fold over a right fold? I’m not entirely sure, but we can make some guesses based on what we’ve found so far.

First, if we want to work with infinite lists we’re going to need a right fold. It can be quite handy to have functions like map (mapFn in previous posts) work with infinite lists, as they can give us elegant ways of writing some functions (for example, finding all square numbers less than 1000: takeWhile (< 1000) (map (^2) [0..]). Thanks to @puffnfresh for this example). So we’d write map as a right fold. This also means we would pick the right fold version of our addOne function (as it is a mapping of (+1) over a list).

If we can’t work with infinite lists (say, because we’re using a strict function like (+)), then we have a choice. We’ve seen arguments are passed in different orders to the function being folded, and the order of evaluation is reversed, either of which may better suit what we are trying to do with our fold. For example, reversing a list using foldLeft (\acc h -> h:acc) [], or just foldLeft (flip (:)) [], seems quite neat.

I’ve seen suggestions to consider loop-like vs. list recursion and operator associativity in making a choice, but I’m not entirely sure how to apply these suggestions yet, so at the moment I’m stuck considering infinite lists and which order of evaluation suits what I’m trying to achieve.

When trying to work out how to write a fold and which variant to use, I find it useful to think about the accumulator (acc) argument in the function we’re folding as delving into the recursion. For left fold the function is (\acc head -> ...), while right is (\head acc -> ...), and the acc argument in both represents the result (or eventual result) of recursing over the rest of the list. This not only helps me to work out if a function can be folded right over an infinite list, but also helps me to work out how I need to implement or compose that function to give me the required result from my fold.

There is one other important difference between the folds we haven’t covered yet, and that is the question of efficiency in time taken and space used. We’ll look at this in the next post.

Conclusion

We’ve now seen a few key differences between left and right folds that give us an idea as to why we’ve bothered coming up with different ways of abstracting away recursion, despite both folds initially looking as if they produced identical results.

First we saw that foldRight takes a function with the accumulator passed in on the right, while foldLeft has it passed in on the left. Depending on the arguments required to the function being folded, this can make certain folds simpler to call in one direction than the other (such as being able to use (:) instead of (++) to build up lists while maintaining its order).

More importantly, we saw that the order of evaluation was different for the folds. Left folds start combining the first element with the initial accumulator, whereas for right folds the last element is the first combined with the initial accumulator value. This causes folding (:) using left fold to reverse a list, while the right fold preserves the initial order.

This evaluation order means left folds don’t work on infinite lists (it needs to get to the final element first before it can start evaluating the expression), while right folds (depending on a function’s strictness) can sometimes work happily with an infinite list. To determine whether a function will work with infinite lists, we need to think about whether that function can return a result without accessing its second parameter (acc, or accumulator).

We can use these differences to decide which type of fold to use. If we need to handle infinite lists then a right fold is our only choice. Otherwise we can consider which evaluation order seems to best suit what we’re trying to achieve. We are also yet to cover a final discriminator, the efficiency of different folds, and this will give us a bit more of a clue as to when we want to use each type of fold. We’ll look at this aspect in the next post of this series, starting with finding a significant problem with our current foldLeft implementation.

In part 1 we found that a fold is a way of abstracting recursive operations over lists. In this post we’ll look at a different way of folding; one that traverses lists in a similar way to a for/foreach loop.

The examples are in Haskell, but I’m not going to assume you’ve had a chance to try it and so I’ll try to explain it as I go. Hopefully the concepts will make sense even if you’re not familiar with Haskell. If you find yourself getting lost in the syntax, I’ve written a Haskell quick start that goes through all the bits we’ll use.

Previously, on davesquared.net…

Last time we looked at recursive functions over lists like this one:

1
2
3

add :: Num a => [a] -> a    -- Take a list of numbers, return a number
add (head:tail) = head + add tail
add [] = 0

We defined our add function as returning the head of the list added to the result of recursively calling add on the rest of the list (known as the tail). We also defined a stopping condition for our recursion: when add is called with an empty list [], it returns 0. Tracing through a call to this function showed something like this:

add [1,3,5]
    = add (1:[3,5])         -- split list into head and tail: 1 and [3,5]
    = 1 + (add [3,5])
    = 1 + (3 + (add [5]))
    = 1 + (3 + (5 + (add [])))
    = 1 + (3 + (5 + 0))     -- recursive calls now stopped. Time to evaluate the expression.
    = 1 + (3 + 5)
    = 1 + 8
    = 9

Here we evaluate the head of the list, and add it to the result of the expression accumulating on the right. Once the recursion reaches the stopping condition we’ve got a long line of brackets accumulated on the right, and we can start evaluating them all until they reduce back to our answer.

In the last post we looked at a few recursive functions like this, and found they all had a few things in common: a seed value to return for the empty list case, and a two argument function that is applied to the head of the list and the accumulated result of calling the original function on the tail of the list. Using this realisation we abstracted the common bits of these recursive operations into a fold function:

1
2
3
4
5
6
7
8

fold :: (a -> b -> b) -> b -> [a] -> b
fold f seed (head:tail) = f head (fold f seed tail)
fold _ seed [] = seed

-- Re-writing add function using fold:
addWithFold :: Num a => [a] -> a
addWithFold list = fold (+) 0 list
    -- (+) is a two arg function. In lambda syntax: (\x y -> x + y)

And this addWithFold function worked exactly the same as our original add function, except we no longer have to explicitly use recursion, it’s abstracted away in our fold function. Tracing through a call to addWithFold showed it expands out exactly as per our original add [1,3,5] example above, including the expressions accumulating on the right (you can see an example of tracing through a fold in part 1).

And that’s where we left things last post.

Writing add using a loop

What if we rewrote our original, recursive version of add using a standard, imperative loop? Let’s see how that would look in a C-like language (in this case, C#):

1
2
3
4
5
6
7

int Add(int[] numbers) {
    int acc = 0;
    for (int i=0; i < numbers.Length; i++) {
        acc += numbers[i];
    }
    return acc;
}

We initialise an accumulator acc to 0, then keep adding each member of the list of numbers to it before returning the final value of acc.

Let’s use a little bit of imagination now. Say C# was actually a language with lazy evaluation like Haskell, so it does not actually evaluate any functions like (+) until it absolutely has to. If we were to trace through the execution of the loop in this lazy world we’d see something like this:

Add(new[] { 1, 3, 5 });
    acc = 0                     // Initial value
    acc = (0 + 1)               // 1st iteration
    acc = ((0 + 1) + 3)         // 2nd iteration
    acc = (((0 + 1) + 3) + 5)   // 3rd iteration and end of loop
    acc = ((1 + 3) + 5)         // Start evaluating...
    acc = (4 + 5)
    acc = 9                     // ... return result

Notice that the here our expression is building up on the left side, instead of on the right-hand side we saw for our version which used fold?

    -- Loop version:
    ((0 + 1) + 3) + 5

    -- Fold version:
    1 + (3 + (5 + 0))

Well, we could also write a Haskell function that uses an accumulator too. But Haskell doesn’t have imperative-style loops, so we’ll need to go back to recursion.

1
2
3
4

add' list =
    let accumulate acc (head:tail) = accumulate (acc+head) tail
        accumulate acc []          = acc
    in accumulate 0 list

Here we’ve used let to introduce a kind of nested function accumulate within add'. It includes an extra variable acc to store our accumulated value. The accumulate function recursively calls itself until it stops at the empty list. Our add' function kicks off this recursion with the initial accumulator value by calling accumulate 0 list.

Now look at what happens when we trace through a call to add':

add' [1,3,5]
    = accumulate 0 [1,3,5]
    = accumulate (0 + 1) [3,5]
    = accumulate ((0 + 1) + 3) [5]
    = accumulate (((0 + 1) + 3) + 5) []  -- stopping condition for recursion, returns acc
    = (((0 + 1) + 3) + 5)                -- recursive calls now stopped. Time to evaluate
    = ((1 + 3) + 5)
    = (4 + 5)
    = 9

Look familiar? This results in the same ((0 + 1) + 3) + 5 expression that is produced by the looping version of the function. We’re accumulating our values in parentheses on the left hand side of our expression.

More examples of loop-style recursions

In part 1 we implemented a few different functions using recursion that built up expressions on their right hand sides. We can also implement these using loop-like recursion as we did for add'. Here are len and mapFn from the previous post, rewritten to accumulate values on the left hand side:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

len :: [a] -> Int
len list =
    let accumulate acc (head:tail) = accumulate (acc+1) tail
        accumulate acc []          = acc
    in accumulate 0 list

mapFn :: (a -> b) -> [a] -> [b]
mapFn f list =
    let accumulate acc (head:tail) = accumulate (acc ++ [f head]) tail  -- (++) concats lists
        accumulate acc []          = acc
    in accumulate [] list

{-
*Main> len [1..10]
10
*Main> mapFn (*2) [1,3,5,7]
[2,6,10,14]
-}

All these functions look strikingly similar. They perform an operation with the acc accumulator and the head of the list, and make a recursive call with this value as the new accumulator. And they all start off with an initial case, commonly called a seed. For add' and len the seed is 0, for mapFn it’s [].

Last post we were able to generalise the common parts of recursive functions into a fold function that accumulated values on the right hand side. Can we write a fold function that evaluates in this loop-like way instead?

Looping using a fold

They key areas of difference between all these functions is the initial seed used for the accumulator, and the operation we perform on the accumulator acc and the head of the list. This means that, similar to the last time we wrote fold, we’re going to have to pass in a seed and a function to operate on acc and head. And we’ll need to pass in a list to fold over.

Type detective work

Let’s try and work out what the types of these arguments need to be. Here’s the types we need to figure out, with placeholders (indicated by question marks) for the argument types and the return type:

foldLeft :: (function?) -> seed? -> list? -> return?

First let’s take a look at the seed. For add' and len we passed in 0, an Int, and this is the type we ended up returning from the functions. For mapFn we passed in a list [], and we ended up returning a list which was the result of applying the mapping to each element. So it looks like the seed and the return value have to be the same type, but it doesn’t really matter what that type is. Let’s just call it type a for now.

foldLeft :: (function?) -> a -> list? -> a

Next let’s look at the list we pass in. For add' this was [Int], a list of Int. For len and mapFn it was any type of list. So this can really be any type of list, and it doesn’t have to be the same type that is used for the seed or the function return value (for example len takes any list [a] and returns an Int which represents the length of the list). So we’ll say the list elements are of any type b, which means it can be any type, but that it does not have to be the same type as our accumulator of type a.

foldLeft :: (function?) -> a -> [b] -> a

The last type we need to figure out is the function that operates on the accumulator acc and the head of the list and returns the new value of the accumulator. For add', this function was acc + head. We already decided that our accumulator is of type a. We also know our list elements are of type b, so the head of the list that gets passed into the function will be something of type b. And then our function returns the new value of the accumulator, which will need to be the same type a as our previous accumulator. So the function will need to have the type a -> b -> a.

All this gives the following type definition:

1

foldLeft :: (a -> b -> a) -> a -> [b] -> a

Here we have 3 arguments: a function that takes an accumulator of type a and a list head of type b and returns the new accumulator; a value of type a as the seed for the accumulator; and a list [b]. Then our function will return the final accumulated value of type a.

I find reasoning about all the types that go flying around quite tricky, but I’ve also found understanding them is a major part of the battle.

Implementing the left fold

Now we need to try and fit all of this together. I’m going to use our add', len and mapFn examples as a template:

1
2
3
4
5

foldLeft :: (a -> b -> a) -> a -> [b] -> a
foldLeft f seed list =
    let accumulate acc (head:tail) = accumulate (f acc head) tail
        accumulate acc []          = acc
    in accumulate seed list

This follows the same format as our previous functions. The only difference is that we’re passing in f and calling f acc head to get the new accumulator value, and that we’re passing in a seed. We can simplify this a bit because we already have the seed argument to foldLeft that we can use as the accumulator (so we don’t need to declare an inner accumulate function):

1
2
3

foldLeft :: (a -> b -> a) -> a -> [b] -> a
foldLeft f acc (head:tail) = foldLeft f (f acc head) tail
foldLeft _ seed [] = seed

If we trace through an example we’ll see it works exactly the same as our previous, loop-like recursion:

foldLeft (+) 0 [1,3,5]
    = foldLeft (+) (0 + 1) [3,5]
    = foldLeft (+) ((0 + 1) + 3) [5]
    = foldLeft (+) (((0 + 1) + 3) + 5) []
    = (((0 + 1) + 3) + 5)
    = ...
    = 9

Now we are able to rewrite our other functions without having to use explicit recursion:

1
2
3
4
5
6
7
8
9
10
11
12

lenLeft :: [a] -> Int
lenLeft list = foldLeft (\acc head -> acc+1) 0 list

mapFnLeft :: (a -> b) -> [a] -> [b]
mapFnLeft f list = foldLeft (\acc head -> acc ++ [f head]) [] list

{-
*Main> lenLeft [1..10]
10
*Main> mapFnLeft (*2) [1..10]
[2,4,6,8,10,12,14,16,18,20]
-}

Left or right?

We now have two versions of folding: foldLeft that works like a loop and accumulates values on the left hand side, and foldRight that accumulates values on the right.

1
2
3
4
5
6
7

foldLeft :: (a -> b -> a) -> a -> [b] -> a
foldLeft f acc (head:tail) = foldLeft f (f acc head) tail
foldLeft _ seed [] = seed

foldRight :: (a -> b -> b) -> b -> [a] -> b
foldRight f seed (head:tail) = f head (foldRight f seed tail)
foldRight _ seed [] = seed

These functions are provided in the standard Haskell Prelude library as foldl and foldr. Both are used to abstract away explicit recursion, and other than our observation about the order it evaluates expression, they both give the same results.

It turns out that this order of evaluation can make a world of difference, especially in a lazily-evaluted language like Haskell. In the next post in this series, we’ll look at some of these differences.

Yet when I’ve asked other devs, most have great personal, work and non-tech goals, but have something to the effect of “become a better developer” thrown in as well. I’ve been thinking about this a bit recently, so thought I’d jot down a couple of thoughts about goals specifically related to software development.

Goals are important

Goals have the potential to motivate us, help us focus, get into a flow, avoid wasting energy, make the most of opportunities we have and, when we reach them, give us a feeling of achievement and growth, along with the happiness that brings.

Many (if not all) of the people I know that I consider really successful are very goal-oriented. They know what they want to achieve and have the skill, self-confidence, and drive to make it happen. For them it seems to come naturally, but I think it is an approach that can be learned and adopted by anyone, irrespective of personality. It’s simply a matter of choosing the right goals; ones that inspire and provide both feedback on progress and a feeling of achievement on meeting them.

Goals with external dependencies

One thing I’ve found really useful in helping to pick goals is to consider which ones depend solely on me, and which ones depend on other people.

Goals like getting a certain number of blog readers, presentations at user groups and conferences, or community recognition all rely on other people. Sure, you have some ability to influence these measures, but the final result is out of your hands. You are not the one in control of whether you meet your goal.

Now I’ve seen these kind of goals work great for people as a way to become better developers (higher profile leads to more opportunities and exchanges of ideas with other top devs), but there are a few reasons they don’t work for me. For one these goals just don’t inspire me, perhaps because I’m a bit of an introvert. Also I don’t have much success in these areas, so you could attribute this to sour grapes ;). But most importantly, I find making progress towards goals plays a crucial part in my motivation and happiness, and I’m not willing to chance either of those things by making them dependent on other people who aren’t even aware of the burden I’ve placed on them.

So for me I need goals that are largely dependent on my own actions.

Non-specific goals

I love learning. I love the process of piecing together little bits of information, until finally something clicks, accompanied by the joy of discovering something I didn’t know before. I guess it’s no surprise then that a number of my goals have been things like “learn (TDD|WPF|Haskell)”.

These make horrible (albeit well-intentioned) goals. The problem is determining when I have achieved them. When have I “learned functional programming”? One of the main things I learn on any topic is becoming aware of more stuff I don’t know – the unknown unknowns. This makes it very tough to get the motivating feeling of progress or the joy of reaching a goal.

These make great, general directions for us to follow, but as goals they just don’t cut it.

Concrete goals for software developers

We’ve ruled out a few types of goals for me so far: goals with external dependencies, and goals based solely on my areas of interest (like learning tech X). Where does that leave me if I want to improve as a software developer? It pretty much just leaves building stuff.

Rather than trying to learn technology X, build a project with technology X. The area of interest sets our direction, and we set an achievable, unambiguous goal out in that direction. This gives us something concrete to focus on, a measure of progress against the project requirements, and the ability to complete our goal and say we’re done. And we’ve got the added benefit that we don’t need 10 people to click our subscribe links, or 3 conferences to accept our talk proposals. It’s completely up to us to work towards our goal, with no external pressures to stifle our creativity, taking us in a direction we’re keen to go, inspired by frequent feedback on our progress, and with the joys of both learning and creating something new.

In keeping with standard guidance for goals, good projects to choose are probably simple, small projects that don’t have to (but can) culminate in polished, shippable products, but are enough to learn and apply the skills being sought. The important things are to make sure it is something that you can build that unambiguously qualifies as achieving the stated goal, and that you’re enthusiastic about it.

A related approach that I’ve found useful is “building” a blog post on the topic I’m interested in. While it’s a bit more ambiguous as to the success I’ve had in meeting my goal, it does provide a way to develop my understanding and relate it to concrete output.

Generating ideas for projects

I thought it was worthwhile to quickly mention this. It can be tough to come up with usable project ideas, so whenever I do come up with one I note it somewhere safe (in a “trusted system” as David Allen would call it). Paper, notebook, task list app, email it to yourself, whatever. Just make sure it is captured and accessible. I’ve found the more I do this, the more ideas I seem to get (although admittedly I still struggle to get lots of inspiring ideas. I do feel capturing everything is slowly helping me improve though). If you’re really stuck try looking up code katas or exercises like Project Euler. But the best projects will be ones that serve a need you have, or fit in with a hobby or subject that really interests you.

Conclusion

Many developers I’ve spoken with have the aim of becoming better developers, but haven’t taken the step of defining what that means. I’ve found it helpful to start translating this into specific goals, and the ones that seem to work best for me are building small projects that relate to an area of interest. I’m also careful to avoid goals that don’t work for me, such as those that depend on external factors and non-specific goals.

If you’ve found other software dev-specific goals and related approaches that work for you, I’d love to hear about them!

Are you still here? Oh. Well, seeing as you don’t seem to want to listen to my advice, you deserve the rest of this post. It features a complete Haskell-n00b sharing his ignorance and misinformation with a reckless disregard for your quest to understand the basics of Haskell in a way that may permanently impair your ability to learn Haskell, understand functional programming, operate heavy machinery, socialise with other humans or be trusted with the weighty responsibility of goldfish ownership.

The aim of this post, despite your reticence to go through an extraordinarily helpful Haskell tutorial, is to get going with the very basics of Haskell insanely quickly and with a minimum of understanding about what’s actually going on. Because that’s just the way I roll. And let’s face it, you deserve it for not taking my advice. ;) (Last chance for redemption.)

Getting to a Haskell interactive prompt

Grab the Haskell Platform from Haskell.org. Once installed, go to your favourite terminal and type ghci to load the Glorious Glasgow Haskell Compilation System interactive environment (assuming ghci is on your path). You should see GHCi’s Prelude> prompt. If you type in something profound like 7*6 and hit return you should get an answer of sorts.

Don’t do it now, but when you want to exit, type :q (in glorious vim tradition).

Loading a Haskell file

Create a blank file called haskell-misinformation.hs in the same directory you ran ghci from. Actually, you can call it whatever you want, but it should end in .hs. Now jump back to your GHCi prompt and type :l haskell-misinformation.hs (you get tab for autocomplete). This will load your file into GHCi. Now whenever we make changes to our Haskell file, we just need to type :r to reload it and pick up our changes.

Here’s what it looks like on my machine:

~  % ghci
GHCi, version 7.0.4: http://www.haskell.org/ghc/  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package ffi-1.0 ... linking ... done.
Prelude> :l haskell-misinformation.hs 
[1 of 1] Compiling Main             ( haskell-misinformation.hs, interpreted )
Ok, modules loaded: Main.
*Main> :r
Ok, modules loaded: Main.
*Main> 

Writing a function

Let’s write an function that takes an integer and increments it. In our Haskell file, type:

1
2

increment :: Int -> Int
increment i = i + 1

Switch back to GHCi and reload our Haskell file by typing :r and hitting return (from now on, we’ll abbreviate this to “reload the file”). If we then type increment 3 into GHCi we should get the unsurprising result of 4.

*Main> :r
[1 of 1] Compiling Main             ( haskell-misinformation.hs, interpreted )
Ok, modules loaded: Main.
*Main> increment 3
4

Notice we don’t need any parentheses for our function call? We just put the arguments straight after the function name.

Let’s take a close look at this syntax. The first line is the type declaration of our increment function. The Int -> Int bit shows the arguments and return type to our function. In this case, increment takes an Int and returns an Int. At first this confused me, having argument types and return types all bundled together like that, with -> arrows thrown around somewhat haphazardly, but it ends up making a lot of sense later on.

But we’re not here to make a lot of sense. We’re here to get started with Haskell quickly. Let’s move on before any accidental learning takes place!

Writing another function

Let’s write an add function that adds two numbers together. Before we do, let’s try and work out that weird, arrow-filled type signature. Our function is going to take 2 Int arguments, and return an Int. So let’s write all that out separated by arrows:

1
2

add :: Int -> Int -> Int
add a b = a + b

Reload the file and run add 3 39. As we saw ealier we don’t use parentheses when calling functions, and now we can see that multiple arguments are separated by spaces. GHCi helpfully tells us the answer is 42. Amazing! Is there anything this Haskell thing can’t do?

Fun with function arguments

Before we go on, try typing :t add into GHCi. It should return add :: Int -> Int -> Int, the type declaration of our function. You can use that to query the types of lots of things, so it’s a handy trick to remember.

Now try typing :t add 5. I get this:

*Main> :t add 5
add 5 :: Int -> Int

Hmmm. The type of add is Int -> Int -> Int, which means it takes 2 integers and returns an integer. The type of add 5 is Int -> Int, which means it takes 1 integer and returns 1 integer. We gave add its first argument and the result is another function which takes the rest of the arguments.

Let’s put that into a new function in our Haskell file and reload it. Our file should look something like this:

1
2
3
4
5
6
7

increment :: Int -> Int
increment i = i + 1

add :: Int -> Int -> Int
add a b = a + b

addFive = add 5

Notice we didn’t put the type declaration in for addFive? That’s because Haskell can infer that for us. In fact, we didn’t need to put in any of the previous ones either. Haskell can work those out too. Hah! Made you type for nothing! Actually I did have my reasons; I feel getting to grips with the type declarations is really important for using Haskell effectively.

Now if we call addFive 10 in GHCi we get 15. This may strike you as a bit strange. Where is addFive’s argument? Shouldn’t we have written addFive a = add 5 a?

Well, that would work too, but we already used :t to determine add 5 is a function that takes one integer and returns another. By writing addFive = add 5 we have just given that function a name.

This is called partial function application. If we just give a few of the arguments a function requires, it will return a function that takes the remainder of the arguments. As an aside, this is the reason for the funny -> symbols in the function type declaration; all Haskell functions take just one argument (warning: don’t click that link if you are feeling lost. You don’t need partial application to understand the rest of this post).

When we don’t know the exact type

So far our type declarations have all involved Int. What if we want to return 42 for any argument of any type? After all, it is the meaning of life, the universe and everything. For that we can use a lowercase placeholder to represent that type (Haskell convention is to use a single character, but I think any string that begins with a lowercase char will do). In this case we’ll use a.

1
2

meaningOfLife :: a -> Int
meaningOfLife x = 42

In the function body we’re putting the argument we get into a variable named x, but no matter what that variable contains, the answer is always 42.

1
2
3
4
5
6
7
8
9
10

*Main> meaningOfLife 123
42
*Main> meaningOfLife 20
42
*Main> meaningOfLife 3.1416
42
*Main> meaningOfLife "hello world"
42
*Main> meaningOfLife []
42

Lists

Haskell has a list type that we can construct using square brackets, as I’ve done in the following GHCi session:

*Main> [1,2,3,4,5,6,7,8]
[1,2,3,4,5,6,7,8]
*Main> [1..8]
[1,2,3,4,5,6,7,8]
*Main> [1,3..8]
[1,3,5,7]
*Main> []
[]

Lists can also be constructed using the cons operator, which in Haskell is :. The : operator takes two arguments. The first is the element you want to add to the front of a list, and the second is an existing list (bonus points if you can work out what the type declaration for this will be before running :t (:)). So we can add 1 to the front of an empty list, or to an existing list:

*Main> 1:[]
[1]
*Main> 1:[2,3,4,5]
[1,2,3,4,5]

In fact, [1,2,3] is actually shorthand for 1:2:3:[] (as pointed out in this tutorial I forgot to mention previously).

We’re really dealing with a linked list here. A Haskell list consists of an initial element, called the head, with a link to the rest of the list, called the tail. There’s even built-in functions to help us get at these bits of the list:

*Main> let myList = [1,2,3,4,5]
*Main> head myList
1
*Main> tail myList
[2,3,4,5]

A String in Haskell is a list of characters, so we can do these same list operations on strings. The string "hello" is the same as 'h':'e':'l':'l':'o':[], so tail "hello" will return "ello"

Pattern matching

I hope you’re still reading (unless you’ve gone off to read Learn You a Haskell of course), because this is such a fun part of Haskell.

When defining a function in Haskell, we can actually provided different function bodies for different patterns of arguments. For example, let’s add this to our Haskell file:

1
2
3

isZero :: Int -> Bool
isZero 0 = True
isZero x = False

When we call this function, Haskell will check the function bodies from top to bottom, and evaluate the first one that matches the pattern for the specified arguments.

*Main> isZero 1
False
*Main> isZero 432
False
*Main> isZero 0
True

We can do much more exciting things than that with patterns though. We can tease apart data types like the lists we were working with earlier.

1
2
3

isFirstItemZero :: [Int] -> Bool
isFirstItemZero (head:tail) = isZero head
isFirstItemZero x = False

Now if we call isFirstItemZero [1,2,3], Haskell will check the first function body. Does [1,2,3] fit the pattern (head:tail)? Remembering that [1,2,3] is the same as 1:[2,3], we can see that it does. So we return isZero 1, which is False. By the same logic we get isFirstItemZero [0,1,2] equal to True.

What about isFirstItemZero []? We can’t break that into a head and a tail, so Haskell will check the next function body. Could [] go into a variable x? If we type let x = [] into GHCi it doesn’t complain, so I guess it can. Haskell evaluates the second function body, so it returns False.

Haskell can work with some truly awesome patterns, but just to show you we’re not limited to single values and basic head/tail, let’s add this to our Haskell file:

1
2
3

hasMoreThanOne :: [a] -> Bool
hasMoreThanOne (first:second:_) = True
hasMoreThanOne _ = False

This will return True whenever the argument fits the pattern (first:second:_). In Haskell, the underscore _ matches anything, so all these will be True:

*Main> hasMoreThanOne (1:2:[])
True
*Main> hasMoreThanOne (1:2:[3,4,5])
True
*Main> hasMoreThanOne [1,2]
True
*Main> hasMoreThanOne [1,2,3,4]
True
*Main> hasMoreThanOne [1..]
True

Anything that doesn’t match that pattern, like [1] or [], will fall through to the second function body and return False.

Pattern matching with recursion

Let’s try an example that uses recursion:

1
2
3

len :: [a] -> Int
len (head:tail) = 1 + len tail
len [] = 0

What happens when we call len [1,2,3]? Well, [1,2,3] gets split into 1:[2,3], so the function returns 1 + len [2,3].

So what’s len [2,3]? The [2,3] gets split into 2:[3], so that will return 1 + len [3]. By the same logic len [3] returns 1 + len [].

What’s len []? That doesn’t have a head and tail, so that falls through to the second method body, which returns 0. So tracing through the whole function call, we get:

len [1,2,3]
    = 1 + len [2,3]
    = 1 + (1 + len [3])
    = 1 + (1 + (1 + len []))
    = 1 + (1 + (1 + 0))
    = 3

Pattern matching with case expressions

If you find the multiple function bodies used for pattern matching confusing, you might find the case syntax easier to follow. In fact, according to Learn You a Haskell, function pattern matching is really just syntactic sugar for case expressions anyway. So we can modify our previous len function like this:

1
2
3
4
5

len :: [a] -> Int
len x =
    case x of
        (head:tail) -> 1 + len tail
        []          -> 0

I find this more confusing, so I’m not going to attempt to explain it, but I’d thought I’d mention it in case it helps you.

Higher-order functions

A higher-order function is one which takes one or more functions as arguments or returns a function (or both). In other words, it has a function in its type declaration. Functions passed to other functions are written with their type declarations surrounded by parentheses.

Let’s write a higher-order function called incrementIf that increments an integer only if another function returns True for that integer. So the function we’re passing through to incrementIf is going to have a type of Int -> Bool – it will take an integer and return true or false, just like a Func<int, bool> in C# if you’re familiar with that. The second argument to incrementIf will be the integer it is working with, and finally incrementIf will return an integer.

1
2

incrementIf :: (Int -> Bool) -> Int -> Int
incrementIf predicate x = if predicate x then increment x else x

Here we have two arguments; the first one being a predicate function, the second being our integer. We’ve also used an if-then-else expression to return the incremented integer if the predicate is true, or else return the integer unchanged.

To test this we can use Haskell’s built in even function (or we could write it ourselves), which will return true or false depending on whether the integer is even.

*Main> incrementIf even 2
3
*Main> incrementIf even 1
1
*Main> incrementIf even 4
5

We can also declare simple functions in-line using lambda syntax. The syntax for lambdas follows the pattern (\ firstArg secondArg ... -> functionBody) (the \ is meant to represent the lambda symbol λ). So rather than using the built-in even function, we could pass our own using a lambda:

*Main> incrementIf (\x -> x `mod` 2 == 0) 5
5
*Main> incrementIf (\x -> x `mod` 2 == 0) 6
7

where and let

The last bit of Haskell I used in my folds post was a where binding. These can be used to pull out part of an expression for clarity, or to remove duplication if the same expression is used in multiple places within a single function. For example, these two functions are equivalent (the ' mark is legal in Haskell function names):

1
2
3
4

circumference radius = 2 * pi * radius

circumference' radius = pi * diameter
    where diameter = 2 * radius

You can also use a let binding for this, which goes before the function body rather than after.

1
2
3

circumference'' radius =
    let diameter = 2 * radius
    in  pi * diameter

The let binding has some other properties (for example, you can use it in lots of places, such as typing let a = 1 into GHCi), but check Learn You a Haskell for more details.

Putting it together

Let’s apply a whole bunch of the things we’ve covered in this post by writing a function that filters a list. This function will have to take another function to do the filtering, which makes it a higher-order function. We’ll also use pattern matching and recursion to work our way through the list. We also want to support any type of list elements, so we’ll need a type signature that reflects that.

If we’re dealing with lists of any element type, let’s just call that type a. If we are filtering elements from a list of a, we’re going to end up with another list of a, so that will also be our return type. The predicate function we pass in to do the actual filtering on each element is going to have to take one of these as, and return True or False.

1

filterList :: (a -> Bool) -> [a] -> [a]

Now let’s try and implement it. We’re going to use pattern matching to break the list argument up into its head and tail. If the head element satisfies the predicate function, then well add that to the head of the result of filtering the tail. Otherwise we’ll drop that head element, and just return the result of filtering the tail. Finally, as a stopping condition for our recursion, we’ll tell Haskell that filtering the empty list will return the empty list, irrespective of what predicate function we pass in.

1
2
3
4

filterList :: (a -> Bool) -> [a] -> [a]
filterList f (head:tail) = if f head then head : filteredTail else filteredTail
    where filteredTail = filterList f tail
filterList _ [] = []

We’ve used where to pull out the filteredTail expression, otherwise we would have had to have filterList f tail in both the if and else conditions. This was just to try and make things neater, but we could have written it all in line too.

Now let’s use some declared functions and lambdas to filter a couple of lists:

*Main> filterList even [1..10]
[2,4,6,8,10]
*Main> filterList odd [1..10]
[1,3,5,7,9]
*Main> filterList isZero [-3..3]
[0]
*Main> filterList (\x -> x > 10) [42, 7, 2, 109, 0, 15]
[42,109,15]
*Main> filterList (\x -> x `mod` 3 == 0) [1..20]
[3,6,9,12,15,18]
*Main> filterList (\x -> x <= 'g') "Hello world, how are you today?"
"He d,  ae  da?"

If you’ve followed this whole filterList example then congratulations on making it successfully through the minefield that was my attempt at a Haskell quick start! Despite my best efforts, you’ve manage to learn a bit of Haskell. :)

Where to from here?

There is loads more to cover before I’d say we know introductory Haskell, particularly function composition, abstract data types (and pattern matching on those), typeclasses, IO, and then on to functors and monads. The best way I know of to get this knowledge in a fun and attainable way is Learn You a Haskell. But we’ve definitely made a start, and hopefully we’ve got enough to start deciphering code samples we see around the place.

Let me know if this helped you at all, or if you want me to go into something in greater detail, or if you’d like me to push further into some of the introductory stuff I’ve picked up so far.

Download the code: haskell-misinformation.hs

This series on folds is my attempt to pull together the little bits and pieces I’ve managed to pick up into a form I can understand. If you’re not familiar with folds, hopefully it will help get you started. If you already know about folds then you probably won’t get much out of this, but if you do read through it I’d love to get corrections via the comments or via email so I can update the post.

In this first post of the series we will try to work out what folds are. We’ll start by looking at some problems we can solve using recursion over lists. We’ll then try and work out what these solutions have in common, and factor that out. Finally we’ll see how this relates to folds, and how we can use folds to solve these problems more succinctly.

Recursing over lists

Let’s look at a Haskell function that uses recursion to return the length of a list.

1
2
3

len :: [a] -> Int
len (head:tail) = 1 + len tail
len [] = 0

The first line declares the type of our len function; it takes a list of any type a (expressed as [a]), and returns an Int.

The second line is where we define the length function in terms of recursion. Given the list argument, we’re going to use pattern matching to break that argument into its head (the first element of the list), and its tail (the rest of the list). For example: the head of the list [1,2,3] is 1 and its tail is [2,3]. When len is called with a list that has a head and tail, we’re going to return 1 plus the result of recursively calling len on the tail. We’ll see an example of this in a minute to make this a bit clearer if you’re lost in the syntax.

What happens when we’ve recursively called len and get to the end of the list? This is what the last line is for; it is the stopping condition for our recursion. If len is called for a list without a head and tail (i.e. the empty list), the pattern on the second line will not be matched and Haskell will look for the next len definition to see if that can provide a return value. Our third line can; it returns the length of the empty list [] as 0.

Let’s manually trace through what happens when we call this function:

len [1,2,3]
    = 1 + len [2,3]
    = 1 + 1 + len [3]
    = 1 + 1 + 1 + len []
    = 1 + 1 + 1 + 0
    = 3

Looks reasonable to me. We’ve defined the length of a list as 1 for its first element (its head) plus the length of the rest (its tail). And when we have a list with no elements (the empty list), its length is 0.

A pattern emerges

What other list functions can we define using recursion? How about adding together all the numbers in a list?

1
2
3
4
5
6
7
8
9
10
11

add :: Num a => [a] -> a  --Take a list of numbers, return a number (all the elements added together)
add (head:tail) = head + add tail
add [] = 0
{- Results:
add [2,4,6]
    = 2 + add [4,6]
    = 2 + 4 + add [6]
    = 2 + 4 + 6 + add []
    = 2 + 4 + 6 + 0
    = 12
-}

This works very similarly to our len function, but instead of adding 1 to get the length, we’re adding the head value to get the sum of all the elements. Adding the elements of an empty list gives us 0. How about mapping a function over every element of the list?

1
2
3
4
5
6
7
8
9
10
11
12
13

mapFn :: (a->b) -> [a] -> [b] -- 1st arg is function that takes an "a" and returns a "b",
                              -- 2nd arg is a list of "a",
                              -- and we return a list of "b".
mapFn fn (head:tail) = (fn head) : mapFn fn tail
mapFn fn [] = []
{- Results:
mapFn (+1) [1,2]
    = (1+1) : mapFn (+1) [2]
    = (1+1) : (2+1) : mapFn (+1) []
    = (1+1) : (2+1) : []    --mapFn of [] is []
    = (1+1) : [3]
    = [2,3]
-}

In this example we’ve defined mapFn as a function fn applied to the head of the list (by calling fn head), then joined the result (using :) to the result of mapping fn over the rest of the list. We’ve also stated that mapping a function over an empty list returns an empty list.

All the functions we’ve seen follow a similar pattern. They operate over a list by splitting the list into head and tail, and return the result of doing something to the head and the result of recursively calling itself on tail. For len, the something was 1+. For add it was head + and for mapFn it was applying fn to the head and joining to the rest of the result. And all of the functions have a value for the empty list to act as a stopping condition (returning 0 or [] in these cases).

Eliminating the duplication

As programmers we eschew duplication, so let’s introduce a function f that will remove the common bits of these functions, and instead let us focus on the important differences between them. What arguments will f need to take? This might end up sounding a bit confusing while we nut it out, but let’s push through it and see if it makes sense once we try and wire it all up at the end.

Our function will need to take a list of some type; all our previous functions have. As I don’t know exactly what type of elements will be in the list, let’s just call them type a as a place holder. We’ll also need to return a result, but what type should the return value be? For len, we used Int; it always returns an Int, even if it is working with a list of characters. So the result does not have to be the same type as the elements in the list; let’s just say it will return some type b.

We’ll also need some value to return for our stopping condition in the case of the empty list (for len this was 0). Now as we’ll be returning this value for the empty list, it will need to be the same type as our return value, which we called type b.

That’s most of the commonalities out of the way. What’s left is the something we do to the head of the list and the result of recursively calling on the tail. That sounds like a function definition to me; it takes the head of our list of as, and the result of calling on the tail (we called the result type b), and returns the final result (also type b).

In Haskell-speak, we now have our function declaration as f :: (a -> b -> b) -> b -> [a] -> b. The first argument is the function that does something with the head and the result of the recursive call with the tail. The second argument is the value we want to use when our list is empty. The third argument is the list of as we’re recursing over. And finally, we’re returning some value of type b.

If you’re feeling a bit lost then that makes two of us. Let’s try and implement it based on what we know and hope for the best. :)

1
2
3

f :: (a -> b -> b) -> b -> [a] -> b
f func valueWhenEmpty (head:tail) = func head (f func valueWhenEmpty tail)
f func valueWhenEmpty [] = valueWhenEmpty

Wat?

If you’re like me then you’re probably thinking our f looks like gobbledegook. Let’s start by looking at the familiar pieces. The last line has our stopping condition for the empty list []; it just returns the required value when the list is empty. Line 2 has our trusty (head:tail) pattern on the left-hand side. What’s the right-hand side doing?

Remember, the first argument (func) is a function that is going to do something with the head of the list and the result of recursively calling on the tail. The f func valueWhenEmpty tail is our recursive call with the tail. If it helps, we could pull out that part of the statement and rewrite the second line like this:

1
2

f func valueWhenEmpty (head:tail) = func head recursiveCallWithTail
    where recursiveCallWithTail = f func valueWhenEmpty tail

Let’s try and apply this to something we already know – our trusty old len function. If we’ve extracted out the common bits of the recursion we should be able to express len in terms of f.

1
2
3
4
5
6
7
8
9

-- original
len :: [a] -> Int
len (head:tail) = 1 + len tail
len [] = 0

-- new
len2 :: [a] -> Int
len2 list = f func 0 list
    where func head lenOfTail = 1 + lenOfTail

I think I’m starting to see how this hangs together now. Our func takes as arguments the head of the list, and the result of recursively calling with tail (which in this case gives the length of the tail). This returns 1 + lenOfTail, which is the same as 1 + len tail from the original len function. We’re also passing in 0 for our empty list value, which gives us the same as the len [] = 0 from the original example.

Let’s step through the evaluation of each function:

len [1,2,3]
    = 1 + len [2,3]
    = 1 + (1 + len [3])
    = 1 + (1 + (1 + len []))
    = 1 + (1 + (1 + 0))
    = 3

len2 [1,2,3]
    = f func 0 [1,2,3]
    = 1 + (f func 0 [2,3])
    = 1 + (1 + (f func 0 [3]))
    = 1 + (1 + (1+ (f func 0 [])))
    = 1 + (1 + (1+0))
    = 3

Here we can see that both len and len2 work exactly the same way, it’s just that len2 is now going via a function that handles the recursion plumbing for us.

Folding

As you may have guessed, our f function is a fold (more specifically, a right fold, which we’ll get to in a later post). We’re folding the func argument over a list and providing a particular value for the stopping condition.

What I’ve been clumsily referring to as “the result of recursively calling the function on the tail” tends to be known as the accumulator, because it represents the accumulation of the results for each element in the tail. The empty list value is known as the seed, as that ends up being the first value of the accumulator once we get to the bottom of the recursion and start working out way back up. Fold itself can also be known as inject or reduce, or Aggregate in .NET.

Let’s quickly express our other examples using our fold function (renamed from f):

1
2
3
4
5
6
7

add2 :: Num a => [a] -> a
add2 list = fold (+) 0 list

mapFn2 :: (a->b) -> [a] -> [b]
mapFn2 fn list = fold (\element acc -> (fn element) : acc) [] list
  -- Here (\a b -> retVal) is a lambda expression that takes 2 arguments.
  -- Think Func<A, B, B> in C#.

But why?!?!

Because it gives us a way of expressing functions that work over lists without the noise of the recursion mechanics getting in the way.

At first the fold versions may seem confusing compared to explicit recursion, but after gaining some familiarity with the steps, folds start to let us immediately focus on the intent of the code. Our function becomes a statement of the absolute essence of the problem we’re solving. The add2 example shows us folding + over a list, starting with a seed of 0. The essence of the function is adding, and there’s the (+) function sitting first and foremost in the call to fold.

Once we start using some Haskell niceties like partial application and function composition we can start getting some very concise, elegant function definitions, expressed in terms of other functions.

Still to come…

In the next post we’ll look at the different types of folds. After that we’ll move on to look at some of the runtime characteristics of folds (and what we can do about them :)).

Well, a couple of reasons. First, I like to write posts in Markdown using Vim. For the last year or so I’ve been converting posts to HTML, piping the output to clipboard, and pasting it into Blogger’s web UI. Switching to a platform that supports Markdown makes that a little simpler. I’ve also never really like the Blogger/Picasa Web image integration thing, so running my own blog means I can dump images wherever I want to and embed away. I also wanted to experiment a bit more with different layouts, but rather than relying on Blogger’s templating system, I wanted to work with straight HTML and CSS (well, via SASS). This would also buy me separation between layout, content, and platform.

If all this sounds a bit tenuous to you then you are probably right. I think all this is justification for me just wanting a change after half a decade on the same platform.

And so you are now reading a static site generated by Octopress, hosted on Heroku. I’ve imported everything over from Blogger and for the most part have kept the same links to avoid breaking stuff. If you find anything amiss or have any problems reading on your browser / feed / device please let me know and I’ll do my best to fix it up (yes, I know the font is large :)).

Thanks to Paul for good naturedly goading me into finally flicking over to Octopress and for helping me out with some questions; Troy, OJ and Tarn for their advice; and Thomas for putting up with all sorts of inane questions I bombarded him with over email and IM.

And finally, thanks to Blogger for an enjoyable 5 years! So long, and thanks for all the posts and fish and stuff. :)

This idea started to dawn on me while I was in Joshua Kerievsky’s Refactoring workshop at YOW 2011. We were going through refactoring exercises, but trying to take extremely small steps to keep the tests green. The final goal could be achieved fairly easily by moving a few chunks of code around while keeping the tests broken for a while, but I really enjoyed the challenge of finding small steps that would keep the tests passing all the way to the final state.

This was further reinforced at Tony’s excellent Functional Programming workshop, where we spent quite a bit of time trying to fit together various functions (and partial applications of them) according to their type signatures. I thoroughly enjoyed this process, despite really struggling to get the solutions much of the time. I also realised I get an extra kick out of these puzzles when there is an element of elegance or simplicity to the way these pieces fit together. For example, implementing map with folds rather than recursion and pattern matching.

I think identifying what you enjoy about programming (or any activity really) can be an important part of maintaining motivation, and improving productivity and creativity as a result. I’m going to put this idea to the test by trying to break down problems in ways that I can use approaches I enjoy, and see if that helps me get better results, both in terms of solution and my happiness and enthusiasm.

This knowledge also helps me better understand some of my weaknesses. I have spent a lot of time over the years trying to piece together various patterns and practices to try and find a process I can continually apply to create great software. In other words, trying to solve the puzzle of how to develop software. My propensity to approach things as puzzles has probably led me astray here, as the unlikelihood of a silver bullet for software development has been demonstrated time and time again. Recognising this, I’ll try be more careful to make sure I’m solving the right problems, and not just inventing problems to puzzle-solve (although that can be educational as well, provided it’s deliberate).

So, what is it about programming you enjoy? Can you use that knowledge to improve the way you work?

Why not QWERTY?

I type reasonably well with QWERTY: normally between 90 - 110 wpm. I started doing some practice to try and improve my accuracy and technique and noticed a few things. First, my right hand tended to drift all over the keyboard (away from the home position), which would result in me sometimes getting lost and making a mistake. A mistake at 110 wpm means typing around 10 characters in the second it takes you to realise it. Backing out those characters, correcting the mistake, correcting your positioning, and continuing gives your typing speed a pretty big hit and is quite frustrating.

Second, my hands had to do all sorts of gymnastics while typing. Common English character combinations like ‘st’, ‘ion’, ‘ce’, ‘ed’ require some big shifts that take you away from the home position (slow and error prone), or require using the same finger for consecutive characters (slow and encourages shortcuts which shift your position).

Third, QWERTY is left-hand biased (at least for English). This can become quite fatiguing. There are also words like ‘minimum’ and the frequently-typed ‘sweaterdresses’ (pointed out on the Colemak site) that rely on a single hand; again, quite fatiguing.

I started to wonder if improving my QWERTY was worthwhile. Maybe I should try an alternate keyboard layout like Dvorak, which was meant to address many of these comfort and accuracy issues (my main goal), and also improve overall speed (a distant second goal).

Why Colemak?

It was around this time I saw @TheColonial mention something about the Colemak layout. I’d never heard of it, but in trying to research what it was I found some promising signs. Colemak was designed to be efficient and ergonomic by keeping commonly used keys on the home row and on the strongest fingers (check out the heatmaps for Colemak et al.), as well as being easy to learn by not deviating too far from QWERTY (the entire bottom left hand is unchanged from QWERTY, which means common shortcuts like Ctrl+Z/X/C/V are unchanged).

If you’ve ever experienced programmer hands, you’ll appreciate why it is important to look after yourself and avoid RSI. I happened across PAT or JK’s keyboard layout analyser, plugged in a few pieces of code and blog posts, and found that, had I typed these using Colemak instead of QWERTY, my fingers would have moved in the order of 50% less to type the same text. Figures like 192m for QWERTY, 97m for Colemak were not uncommon. It also tended to beat out Dvorak. How could anyone interested in efficiency not try that out?

Three weeks with Colemak

I started out doing Colemak exercises with aTypeTrainerForMac. Largely due to its commonalities with QWERTY, the layout itself was quite easy to learn. I had the key positions memorised by the end of the first day, but using it effectively was another matter entirely.

No matter how well I knew the individual keys, I found my brain wanted to think about typing a whole word or pattern at a time. I could start typing the first few characters in Colemak, get to a familiar pattern like ‘ion’, and my brain would leap ahead and get me to complete the word (incorrectly) in QWERTY. Getting my reason to fight these reflexes was very uncomfortable, but at the same time a fascinating insight into how the brain works.

After 1 week of fairly intense practice, I could type steadily at 20 wpm with Colemak, but my QWERTY had dropped a bit to 80.

Shortly after that (with the help of autocomplete) I was able to use Colemak pretty effectively. After three weeks of almost exclusive use I could type between 40-50 wpm and it felt very comfortable. My technique and accuracy were improving.

It was then I found my QWERTY was down to 15 wpm. That is not a typo; a measly 15 wpm. I was completely unable to use a standard keyboard.

Return of the QWERTY

I was a few days away from attending a Code Retreat in Brisbane, and was really concerned about being able to pair with people when I couldn’t type properly. I decided to jump back into QWERTY full time. It took a solid day, but after being completely useless for an hour or so the reflexes started to come back. By the end of the day I was back to 90 wpm (provided I didn’t think too hard about it :)). Surprisingly I could still type ~30 wpm on Colemak.

One thing that really surprised me is how clumsy QWERTY felt to me. I could feel the added strain on my fingers, wrists and shoulders due to the increased movement. Accuracy seemed to come much easier with Colemak, although that could have been a product of how I had trained myself up on all the characters, rather than on real text. I also really started to notice the bad touch typing habits I had formed with QWERTY, like leaving the home row and using wrong fingers to hit keys due to the key positions of many words.

Current state

I’m really undecided on how to proceed from here. One one hand Colemak really seems a lot more comfortable, and I’m pretty confident I could get up to comparable levels of speed with it.

On the other hand, almost every other keyboard in the English-speaking world uses QWERTY. It’s obviously going to take me a bit of work to maintain proficiency with both QWERTY and Colemak. The alternative, being unable to use most other computers effectively, is very unappealing. If I was only ever going to use my own computer I’d almost definitely stick with Colemak, but as I do a lot of pair programming it really comes down to exactly how much effort it’s going to take to be bi-typal.

If we end up getting QIDO for Colemak it may help for pair programming, but I’m still concerned about being stuck at some random computer and being unable to use it.

My other concern is that my perceived increase in comfort with Colemak is at half the speed of my QWERTY typing. I’m not sure whether Colemak would still be comfortable once I hit 100 wpm, or whether I would get the same discomfort as I do with QWERTY.

So there you have it; a bit of a non-conclusion. Colemak seems to have a lot of things going for it, but it’s hard to recommend it in the face of the ubiquity of QWERTY and with only anecdotal evidence of it’s ergonomic benefits (and there’s some counter-anecdotes too). It’s definitely an interesting experiment to try, just for some insight in to how your brain works with typing, but unless you only use your own hardware I’d suggest keeping up speed on QWERTY as well.

As for me, I think I’ll try and develop both QWERTY and Colemak in parallel for a while and see what happens.

I’m currently battling some driver signing issues. We have some incomplete documentation from a previous occasion we’ve been through a related problem, but no one remembers the exact steps used. Because this previous occasion was reasonably considered a one-off, it was never automated. If it had been, it would now provide reliable, repeatable, unambiguously documented steps for getting me out of my current jam. Even if not an exact match for my current requirements, having a working example I could use as a basis to work from would be invaluable.

This has made me think that it is probably worth automating a whole bunch of tasks I hadn’t previously considered due to their infrequent nature. What better documentation of a procedure than working, executable steps? Sure, there may be a need for accompanying rationale, but given a blind choice between a Word/wiki document and something that actually runs and works, I’m picking the latter.

Don’t mock types you don’t own

I’ve written about this before, and I still think it is good advice. Test down to your lowest level of abstraction, then integration / contract / acceptance test over the boundary. By mocking a type you don’t own that dependency starts bleeding in to your code and pushing your own abstractions in potentially unhelpful ways. You’re also not really testing much; unless you also have good contract tests then checking you’ve called a specific external method is not going to tell you much about whether your code does what it needs to.

Contrived example: say I was faking out Math.Round() (let’s pretend it’s an instance method or you are using a framework that can mock statics via the profiler API):

[Test]
public void Calculate_with_rounding() {
    math.Round(2.5).Returns(3); //Fake math.Round
    var subject = new Calculation(math);

    Assert.AreEqual(subject.AddAndRound(1, 1.5), 3);
}

Perfectly reasonable? Well, except for the fact .NET uses banker’s rounding and rounds 2.5 to 2 (and 1.5 to 2 for that matter). If you were using Python (which rounds away from 0), you would have been spot on. If you care about the rounding method, you’ve now got a bug.

If something as simple as rounding can trip us up, imagine what we could do if we start mocking ORM or ADO.NET calls.

Try to avoid mocks in acceptance tests

In my experience this tends to result in too much behaviour being pushed into the mocks. My first preference is to use real pieces, second is to hand-code fakes that have enough logic to work as required, and convenience methods to help tests configure them appropriately. As per "don’t mock types you don’t own", it is also a good idea to test your fakes match the real behaviour.

Learn mocking before a mocking framework

I’ve often heard developers new to automated testing say things like "I really need to learn (Rhino Mocks | Moq | Mocking Framework X)". I think this is the wrong emphasis; before learning a framework for creating test doubles it’s important to understand how test doubles work and how to use them.

For me, a great way to learn was to hand-roll all my fake objects for my tests to act as required. Manually stubbing out values and/or recording calls gave me a good understanding of the different types of test doubles (mocks, spies, stubs etc.) and how they work. Once this got old (very quickly) it was fairly simple to take the behaviour I knew how to hand-code and translate that into the syntax required by a mocking framework. It just became a matter of automating what I was already doing. (It also helped me understand common difficulties like trying to mock non-virtual members.)

Don’t explictly test intermediate steps or inconsequential details

If we assert on details of an implementation we tend to get tight coupling and brittle tests. An example I have seen fairly frequently is:

[Test]
public void Should_get_the_widget_from_the_factory() {
    var factory = MockRepository.GenerateMock<IWidgetFactory>();
    var subject = new Foo(factory);
    subject.DoStuff();
    factory.AssertWasCalled(x => x.GetWidget());
}

[Test]
public void Should_turn_the_widget() {
    var widget = MockRepository.GenerateMock<IWidget>();
    var factory = MockRepository.GenerateStub<IWidgetFactory>();
    factory.Stub(x => x.GetWidget()).Return(widget);
    var subject = new Foo(factory);
    subject.DoStuff();
    widget.AssertWasCalled(x => x.Turn());
}

Here the first test is a completely redundant. The second test covers that entire code path (how else could the widget from the factory get turned, if the subject did not call the factory?). Now you could argue that you prefer the extra, explicit specification the first test provides, to which I’d respond that I don’t think it’s worth the pain from the additional friction it causes when you want to change this implementation detail.

Besides, what do we really care about for our subject? That it uses a factory? Or that it turns the widget? Focus on how you want the object to behave, not how it implements that behaviour.

This approach can help lead us to better abstractions, as we start identifying roles and responsibilities separately from implementation details. And it will definitely make your code easier to change without the friction of over-specified tests.

Mock interaction with the contract, not the specific implementation

On a highly related point, the aim of abstraction is decoupling from the implementation. If we are configuring our test doubles with lots of behaviour that our unit tests are relying on then our object is coupled to that particular implementation, not to a contract of behaviour or a role. For an abstraction to be effective we should be able to drop in a completely new implementation that fulfils the required role. This is not the case if we need to set up a test double’s method to call another dependency and return some rearrangement of the result. If we’re relying on that in our test then our abstraction has failed.

Sometimes you just get stuck with having to perform a callback from a stub, but in general if you are pushing behaviour into your mock, re-think the design or consider using a hand-coded fake before you go contorting your mocking framework.

Beware over-abstraction

It is quite easy to churn out layers of useless abstractions when using mock frameworks. Abstractions have a cost. Feedback from tests is great, but pay close attention to SOLID and the rules of simple design and call out to meaningful abstractions, rather than putting in a dependency just for testing. I wrote some guidelines on abstractions a while back that I don’t entirely disagree with yet.

Some unanswered questions

Mocks vs. stubs, tell vs. ask.

I’ve tended to prefer stubs over mocks (stubbing out the results of calls rather than checking they were received), as per the widget factory example above. This flies in the face of the "Tell, don’t ask" principle, which recommends we don’t ask a collaborator for some state and act on the result, but instead give the collaborator the state it needs from us and tell it what to do with it. This seems to suggest I should be using mocks (checking received calls) a whole lot more than I stub them out.

Avoiding "Yet Another Factory"

If an object news up something, our unit test will typically have almost no ability to affect that object. If we want to check our subject news up a view model and calls Activate() on it, we have no way of asserting this was done without exposing IsActivated and relying on that implementation detail. Leaky abstraction. Bad.

One solution is injecting a factory into our object. We can stub out what this returns, make it return another test double, and then check it received the Activate() call. Just introduce a factory. Yet another factory. Searching through files matching *Factory becomes an exercise akin to reading War and Peace. And they’re generally not even real factories! They don’t choose a particular implementation, they are just a glorified wrapper over a single constructor.

Sure, I sometimes try to ease my conscience by injecting a factory method as a Func<T> which my IoC container helps me with. But deep down I know its still YAF, and a small part of me dies.

I’m hoping choosing "better" abstractions will help me with this, but I’ve had limited success to date.

Interface explosion

C# seems to make it difficult to do testing without using interfaces. And so I end up pulling out yet another interface that will never see another implementation. I’ve heard Shannon refer to them as "the new header files". Every class has its interface documented in its header/interface file. It’s easy to say just choose better abstractions where the interface can be reused, but this is still something I struggle with.

Mocking in dynamic languages

This post has been written primarily from the perspective of static languages; I not sure how much (if any) applies to dynamic languages. From my limited experience testing and mocking seem to be done quite differently in languages like Ruby and Python. I’m keen to learn more about how mocking is done in these languages and see how much can help me improve how I test.

End of transmission

This has been a brain dump of my current opinions about mocking. If you agree, disagree, and/or can help me with some of my unanswered questions, please leave a comment.

Now if you’ll excuse me, I’m off to code up yet another factory…

We had a branch checked out with 2 new commits on it, and we wanted to squash it into a single commit using git rebase -i (basecommit). This would start the normal interactive rebase, then get into a loop of printing the following error to console:

mv: cannot move '.git/rebase-merge/git-rebase-todo.new' to '.git/rebase-merge/git-rebase.todo'

Looking at the .git/rebase-merge folder, I could see the git-rebase-todo.new file getting repeatedly created, then deleted. This was happening on two different machines.

Some googling lead me to this post which suggested a virus checker may be locking the file.

Sure enough, turning off Microsoft Security Essentials’ Real-time protection, doing the rebase, then turning it back on again, resolved the problem. I’ve never had this problem before so must have just gotten “lucky” with this particular file matching some property the virus checker was looking for.

I guess this is probably worth trying whenever getting strange file IO errors from any software ported to Windows.