Yesterday I was talking about F# at the .NET Developer Group Braunschweig. It was my first talk completely without PowerPoint (just Live-Coding and FlipChart) and I have to admit this is not that easy. But the event was really a big fun and we covered a lot of topics like FP fundamentals, concurrency and domain specific languages (of course I showed â€œFAKE â€“ F# Makeâ€).

Now I have a bit time before I go to the next BootCamp in Leipzig. Today Christian Weyer will show us exciting new stuff about WCF and Azure.

In the meanwhile I will write here about another important question (see first article) from the F# BootCamp in Leipzig:

##### Question 4 â€“ Try to explain â€œCurryingâ€ and â€œPartial Applicationâ€. Hint: Please show a sample and use the pipe operator |>.

Obviously this was a tricky question for FP beginners. There are a lot of websites, which give a formal mathematical definition but donâ€™t show the practical application.

â€œCurrying â€¦ is the technique of transforming a function that takes multiple arguments (or more accurately an n-tuple as argument) in such a way that it can be called as a chain of functions each with a single argumentâ€

I want to show how my pragmatic view of the terms here, so letâ€™s consider this small C# function:

public int Add(int x, int y) { return x + y; }

Of course the corresponding F# version looks nearly the same:

`let add(x,y) = x + y`

But letâ€™s look at the signature: *val add : int * int â€“> int*. The F# compiler is telling us

**add**wants a tuple of ints and returns an int. We could rewrite the function with one blank to understand this better:

`let add (x,y) = x + y`

As you can see the add function actually needs only one argument â€“ a tuple:

let t = (3,4) // val t : int * int printfn "%d" (add t) // prints 7 â€“ like add(3,4)

Now we want to curry this function. If youâ€™d ask a mathematician this a complex operation, but from a pragmatic view it couldnâ€™t be easier. Just remove the brackets and the comma â€“ thatâ€™s all:

`let add x y = x + y`

Now the signature looks different: *val add : int -> int â€“> int*

But whatâ€™s the meaning of this new arrow? Basically we can say if we give one int parameter to our add function we will get a function back that will take only one int parameter and returns an int.

let increment = add 1 // val increment : (int -> int) printfn "%d" (increment 2) // prints 3

Here â€œincrementâ€ is a new function that uses partial application of the curryied add function. This means we are fixing one of the parameters of **add **to get a new function with one parameter less.

But why are doing something like this? Wouldnâ€™t it be enough to use the following increment function?

let add(x,y) = x + y // val add : int * int -> int let increment x = add(x,1) // val increment : int -> int printfn "%d" (increment 2) // prints 3

Of course we are getting (nearly) the same signature for increment. But the difference is that we can not use the forward pipe operator **|>** here. The pipe operator will help us to express things in the way we are thinking about it.

Letâ€™s say we want to filter all even elements in a list, then calculate the sum and finally square this sum and print it to the console. The C# code would look like this:

var list = new List<int> {4,2,6,5,9,3,8,1,3,0}; Console.WriteLine(Square(CalculateSum(FilterEven(list))));

If we donâ€™t want to store intermediate results we have to write our algorithm in reverse order and with heavily use of brackets. The function we want to apply last has to be written first. This is not the way we think about it.

With the help of curried functions, partial application and the pipe operator we can write the same thing in F#:

let list = [4; 2; 6; 5; 9; 3; 8; 1; 3; 0] let square x = x * x

list |> List.filter (fun x -> x % 2 = 0) // partial application |> List.sum |> square |> printfn "%A" // partial application

We describe the data flow in exactly the same order we talked about it. Basically the pipe operator take the result of a function and puts it as the **last** parameter into the next function.

What should we learn from this sample?

- Currying has nothing to do with spicy chicken.
- The |> operator makes life easier and code better to understand.
- If we want to use |> we need curryied functions.
- Defining curryied functions is easy â€“ just remove brackets and comma.
- We donâ€™t need the complete mathematical theory to use currying.
- Be careful with the order of the parameter in a curryied function. Donâ€™t forget the pipe operator puts the parameter from the right hand side into your function â€“ all other parameters have to be fixed with partial application.