Today I’m starting a new blog post series about solving code katas in F# and with the help of my NaturalSpec project. A code kata is a programming exercise which helps to improve your skills through practice and repetition. In this series we want to use the Test Driven Development TDD approach which means in the context of NaturalSpec that we have to write our specs before we implement the algorithm.

#### Problem Description

“The game of yahtzee is a simple dice game. Each round, each player rolls five six sided dice. The player may choose to reroll some or all of the dice up to three times (including the original roll). The player then places the roll at a category, such as ones, twos, sixes, pair, two pairs etc. If the roll is compatible with the score, the player gets a score for this roll according to the rules. If the roll is not compatible, the player gets a score of zero for this roll.

The kata consists of creating the rules to score a roll in any of a predefined category. Given a roll and a category, the final solution should output the score for this roll placed in this category.”

[codingdojo.org]

##### Category 1 – Ones, Twos, Threes, Fours, Fives, Sixes

“Ones, Twos, Threes, Fours, Fives, Sixes: The player scores the sum of the dice that reads one, two, three, four, five or six, respectively. For example, 1, 1, 2, 4, 4 placed on "fours" gives 8 points.”

After reading this category description we could come up with the following spec:

module Yahtzee.Specs

open NaturalSpec

let placed_on category list =

printMethod category

calcValue category list

[<Scenario>]

let “Given 1,1,2,4,4 placed on "fours" gives 8 points.“ () =

Given (1, 1, 2, 4, 4)

|> When (placed_on Fours)

|> It should equal 8

|> Verify

Since we really want to implement six different categories we should also add some more scenarios like this one:

[<Scenario>]

let “Given 1,1,6,4,6 placed on "sixes" gives 12 points.“ ()=

Given (1, 1, 6, 4, 6)

|> When (placed_on Sixes)

|> It should equal 12

|> Verify

// …

Now we have some specs but they will all fail since we don’t have anything implemented yet. So we have to come up with a model of dice rolls and categories. As the specs suggests we model the dice roll as a tuple of ints and the category as a discriminated union:

module Yahtzee.Model

type Roll = int * int * int * int * int

type Category =

| Ones

| Twos

| Threes

| Fours

| Fives

| Sixes

The tuple is a natural choice for the dice roll, but for easier calculation we add a helper function which converts it into a list. This allows use to use the standard list functions and therefore summing the values becomes trivial:

let toList (roll:Roll) =

let a,b,c,d,e = roll

[a;b;c;d;e]

let sumNumber number =

Seq.filter ((=) number)

>> Seq.sum

let calcValue category roll =

let list = toList roll

match category with

| Ones -> sumNumber 1 list

| Twos -> sumNumber 2 list

| Threes -> sumNumber 3 list

| Fours -> sumNumber 4 list

| Fives -> sumNumber 5 list

| Sixes -> sumNumber 6 list

Now we can run our scenarios with any NUnit runner. I’m using the default NUnit GUI runner here, which gives me a picture like this:

##### Category 2 – Pair

“Pair: The player scores the sum of the two highest matching dice. For example, 3, 3, 3, 4, 4 placed on "pair" gives 8.”

The kata description gives us some new scenarios. As seen above we should specify them before writing the code.

[<Scenario>]

let “Given 3,3,3,4,4 placed on "pair" gives 8.“ () =

Given (3, 3, 3, 4, 4)

|> When (placed_on Pair)

|> It should equal 8

|> Verify

[<Scenario>]

let “Given 5,3,5,4,4 placed on "pair" gives 10.“ () =

Given (5, 3, 5, 4, 4)

|> When (placed_on Pair)

|> It should equal 10

|> Verify

[<Scenario>]

let “Given 1,2,3,4,5 placed on "pair" gives 0.“ () =

Given (1, 2, 3, 4, 5)

|> When (placed_on Pair)

|> It should equal 0

|> Verify

Since we use a new category we now have to extend our model and the **calcValue** function:

type Category =

| Ones

// …

| Sixes

| Pair

// …

let sumAsPair list number =

let numberCount =

list

|> Seq.filter ((=) number)

|> Seq.length

if numberCount >= 2 then 2 * number else 0

let calcValue category roll =

let list = toList roll

match category with

| Ones -> sumNumber 1 list

// …

| Sixes -> sumNumber 6 list

| Pair ->

[1..6]

|> Seq.map (sumAsPair list)

|> Seq.max

##### Category 3 – Two pairs

“Two pairs: If there are two pairs of dice with the same number, the player scores the sum of these dice. If not, the player scores 0. For example, 1, 1, 2, 3, 3 placed on "two pairs" gives 8.”

[<Scenario>]

let “Given 1,1,2,3,3 placed on "two pair" gives 8.“ () =

Given (1, 1, 2, 3, 3)

|> When (placed_on TwoPair)

|> It should equal 8

|> Verify

[<Scenario>]

let “Given 1,6,6,3,3 placed on "two pair" gives 18.“ () =

Given (1, 6, 6, 3, 3)

|> When (placed_on TwoPair)

|> It should equal 18

|> Verify

[<Scenario>]

let “Given 1,1,2,4,3 placed on "two pair" gives 0.“ () =

Given (1, 1, 2, 4, 3)

|> When (placed_on TwoPair)

|> It should equal 0

|> Verify

Implementing this category is a little bit tricky but with the help of our Pair function and some more standard sequence combinators we can get our spec green:

type Category =

| Ones

// …

| TwoPair

let allPairs =

[for i in 1..6 do

for j in 1..6 -> i,j]

let calcValue category roll =

// …

| TwoPair ->

allPairs

|> Seq.filter (fun (a,b) -> a <> b)

|> Seq.map (fun (a,b) ->

let a’ = sumAsPair list a

let b’ = sumAsPair list b

if a’ = 0 || b’ = 0 then 0 else a’ + b’)

|> Seq.max

##### Category 4 – Three of a kind

“Three of a kind: If there are three dice with the same number, the player scores the sum of these dice. Otherwise, the player scores 0. For example, 3, 3, 3, 4, 5 places on "three of a kind" gives 9.”

[<Scenario>]

let “Given 3,3,3,4,5 placed on "three of a kind" gives 9“()=

Given (3, 3, 3, 4, 5)

|> When (placed_on ThreeOfAKind)

|> It should equal 9

|> Verify

[<Scenario>]

let “Given 3,4,3,4,5 placed on "three of a kind" gives 0“()=

Given (3, 4, 3, 4, 5)

|> When (placed_on ThreeOfAKind)

|> It should equal 0

|> Verify

Now it is time to refactor our code. The **sumAsPair** function should be extended to a sumAsTuple function:

type Category =

| Ones

// …

| ThreeOfAKind

let sumAsTuple value list number =

let numberCount =

list

|> Seq.filter ((=) number)

|> Seq.length

let takeBestTuple value list =

[1..6]

|> Seq.map (sumAsTuple value list)

|> Seq.max

if numberCount >= value then value * number else 0

let calcValue category roll =

// …

| Pair -> takeBestTuple 2 list

| TwoPair ->

allPairs

|> Seq.filter (fun (a,b) -> a <> b)

|> Seq.map (fun (a,b) ->

let a’ = sumAsTuple 2 list a

let b’ = sumAsTuple 2 list b

if a’ = 0 || b’ = 0 then 0 else a’ + b’)

|> Seq.max

| ThreeOfAKind –> takeBestTuple 3 list

##### Category 5 – Four of a kind

“Four of a kind: If there are four dice with the same number, the player scores the sum of these dice. Otherwise, the player scores 0. For example, 2, 2, 2, 2, 5 places on "four of a kind" gives 8.”

[<Scenario>]

let “Given 2,2,2,2,5 placed on "four of a kind" gives 8“ ()=

Given (2, 2, 2, 2, 5)

|> When (placed_on FourOfAKind)

|> It should equal 8

|> Verify

[<Scenario>]

let “Given 2,6,2,2,5 placed on "four of a kind" gives 0“ ()=

Given (2, 6, 2, 2, 5)

|> When (placed_on FourOfAKind)

|> It should equal 0

|> Verify

With the help of the takeBestTuple function this becomes trivial:

type Category =

| Ones

// …

| FourOfAKind

let calcValue category roll =

// …

| FourOfAKind -> takeBestTuple 4 list

##### Category 6 – Small straight

“Small straight: If the dice read 1,2,3,4,5, the player scores 15 (the sum of all the dice), otherwise 0.”

[<Scenario>]

let “Given 1,2,3,4,5 placed on "Small Straight" gives 15“()=

Given (1,2,3,4,5)

|> When (placed_on SmallStraight)

|> It should equal 15

|> Verify

[<Scenario>]

let “Given 1,2,5,4,3 placed on "Small Straight" gives 15“()=

Given (1,2,5,4,3)

|> When (placed_on SmallStraight)

|> It should equal 15

|> Verify

[<Scenario>]

let “Given 1,2,6,4,3 placed on "Small Straight" gives 0“()=

Given (1,2,6,4,3)

|> When (placed_on SmallStraight)

|> It should equal 0

|> Verify

As in all the above scenarios we don’t assume any specific order in our rolls but for this category it is easier to test if the data is sorted:

type Category =

| Ones

// …

| SmallStraight

let calcValue category roll =

// …

| SmallStraight ->

match list |> List.sort with

| [1;2;3;4;5] -> 15

| _ -> 0

##### Category 7 – Large straight

“Large straight: If the dice read 2,3,4,5,6, the player scores 20 (the sum of all the dice), otherwise 0.”

[<Scenario>]

let “Given 2,3,4,5,6 placed on "Large Straight" gives 20“()=

Given (2,3,4,5,6)

|> When (placed_on LargeStraight)

|> It should equal 20

|> Verify

[<Scenario>]

let “Given 6,2,5,4,3 placed on "Large Straight" gives 20“()=

Given (6,2,5,4,3)

|> When (placed_on LargeStraight)

|> It should equal 20

|> Verify

[<Scenario>]

let “Given 1,2,6,4,3 placed on "Large Straight" gives 0“()=

Given (1,2,6,4,3)

|> When (placed_on LargeStraight)

|> It should equal 0

|> Verify

Of course the implementation is exactly the same as for the small straight:

type Category =

| Ones

// …

| LargeStraight

let calcValue category roll =

// …

| LargeStraight ->

match list |> List.sort with

| [2;3;4;5;6] -> 20

| _ -> 0

##### Category 8 – Full house

“Full house: If the dice are two of a kind and three of a kind, the player scores the sum of all the dice. For example, 1,1,2,2,2 placed on "full house" gives 8. 4,4,4,4,4 is not "full house".”

[<Scenario>]

let “Given 1,1,2,2,2 placed on "full house" gives 8.“ () =

Given (1,1,2,2,2)

|> When (placed_on FullHouse)

|> It should equal 8

|> Verify

[<Scenario>]

let “Given 4,4,4,4,4 placed on "full house" gives 0.“ () =

Given (4,4,4,4,4)

|> When (placed_on FullHouse)

|> It should equal 0

|> Verify

[<Scenario>]

let “Given 1,1,2,3,2 placed on "full house" gives 0.“ () =

Given (1,1,2,3,2)

|> When (placed_on FullHouse)

|> It should equal 0

|> Verify

Implementing the FullHouse category is easy if we reuse our solutions to the Two pairs category:

type Category =

| Ones

// …

| FullHouse

let takeBestCombo value1 value2 list =

allPairs

|> Seq.filter (fun (a,b) -> a <> b)

|> Seq.map (fun (a,b) ->

let a’ = sumAsTuple value1 list a

let b’ = sumAsTuple value2 list b

if a’ = 0 || b’ = 0 then 0 else a’ + b’)

|> Seq.max

let calcValue category roll =

// …

| TwoPair -> takeBestCombo 2 2 list

// …

| FullHouse -> takeBestCombo 2 3 list

##### Category 9 – Yahtzee

“Yahtzee: If all dice are the have the same number, the player scores 50 points, otherwise 0.”

Here we can use NaturalSpec’s ScenarioTemplates in order to specify all Yahtzees:

[<ScenarioTemplate(1)>]

[<ScenarioTemplate(2)>]

[<ScenarioTemplate(3)>]

[<ScenarioTemplate(4)>]

[<ScenarioTemplate(5)>]

[<ScenarioTemplate(6)>]

let “Given n,n,n,n,n placed on "Yahtzee" gives 50.“ n =

Given (n,n,n,n,n)

|> When (placed_on Yahtzee)

|> It should equal 50

|> Verify

[<Scenario>]

let “Given 1,1,1,2,1 placed on "Yahtzee" gives 50.“ () =

Given (1,1,1,2,1)

|> When (placed_on Yahtzee)

|> It should equal 0

|> Verify

The implementation is pretty easy:

type Category =

| Ones

// …

| Yahtzee

let calcValue category roll =

// …

| Yahtzee ->

let a,b,c,d,e = roll

if a = b && a = c && a = d && a = e then 50 else 0

##### Category 10 – Chance

“Chance: The player gets the sum of all dice, no matter what they read.”

[<Scenario>]

let “Given 1,1,1,2,1 placed on "Chance" gives 6.“ () =

Given (1,1,1,2,1)

|> When (placed_on Chance)

|> It should equal 6

|> Verify

[<Scenario>]

let “Given 1,6,1,2,1 placed on "Chance" gives 11.“ () =

Given (1,6,1,2,1)

|> When (placed_on Chance)

|> It should equal 11

|> Verify

This seems to be the easiest category as we only have to sum the values:

type Category =

| Ones

// …

| Chance

let calcValue category roll =

// …

| Chance -> List.sum list

##### Conclusion

We used a lot of F#’s sequence combinators, pattern matching and discriminated unions in this kata. I think this shows that F# is very well suited for such a problem and with NaturalSpec we can easily use a TDD/BDD approach.

The complete source code can be found in the NaturalSpec repository.

If you want to know more about a specific part of the kata or NaturalSpec feel free to contact me.

Tags:

BDD,

Code Quality,

F#,

Kata,

KataYahtzee,

NaturalSpec,

nunit,

TDD
In my last article (Introducing NaturalSpec – A Domain-specific language (DSL) for testing) I used NaturalSpec in two small samples. This time I will show how we can set up a NaturalSpec environment to write our first automatically testable scenarios.

##### 1. Choosing an IDE

The first step is to choose an integrated development environment for NaturalSpec. At the current project status you should be able to use NaturalSpec with Visual Studio 2008, Visual Studio 2010 beta 2, the freely available Visual Studio 2008 Shell or the free IDE SharpDevelop 3.0.

##### 2. Installing the testing framework

As NaturalSpec uses NUnit as the underlying testing framework we have to install NUnit 2.5. I also recommend installing TestDriven.Net in order to get a Unit Test runner within Visual Studio.

##### 3. Installing F#

NaturalSpec is completely written in F# and all specs will also be written in F#. This doesn’t imply you have to learn programming in F# but we need the F# compiler to get things working. You can download the F# October 2009 CTP from the Microsoft F# Developer Center.

##### 4. Downloading the latest version of NaturalSpec

You can download a .zip with the latest NaturalSpec libraries from GoogleCode.

##### 5. Creating a spec

This part is written for using Visual Studio 2008. If you use SharpDevelop or Visual Studio 2008 Shell this might differ in some detail.

Start Visual Studio 2008 and create a new F# class library.

Rename *Module1.fs* in *ListSpec.fs* and delete *script.fsx* from the project:

Create a folder “Lib” and unzip the NaturalSpec libraries into it.

Add *NaturalSpec.dll* and *nunit.framework.dll* as references to your project:

Copy the following code into ListSpec.fs:

module ListSpec

open NaturalSpec
[<Scenario>]
let When_removing_an_3_from_a_small_list_it_should_not_contain_3() =
Given [1;2;3;4;5]
|> When removing 3
|> It shouldn't contain 3
|> Verify

If you have TestDriven.Net installed you can run your spec via right click in the solution explorer:

If you don’t like the TestDriven.Net test runner you might want to use the NUnit GUI runner. The output should look like:

In addition the test runner should produce a Spec output file with the name “Spec.txt” within the same folder.

##### Summary

In a minimal environment you need SharpDevelop, the F# compiler, NUnit and the NaturalSpec libraries for using NaturalSpec.

In the next post I will show how you can use NaturalSpec to create a spec for C# projects.

Tags:

BDD,

F#,

NaturalSpec,

nunit,

TDD,

Visual Studio
This is the third part in a “Questions and Answers”-series about the F# BootCamp in Leipzig. This time we will look at lazy evaluation.

##### Question 5 – What is the difference between “Lazy Evaluation” and “Eager evaluation”?

**Lazy evaluation** is a technique of delaying a computation until the result is required. If we use **eager evaluation** an expression is evaluated as soon as it gets bound to a variable.

One participant answered that lazy evaluation is used in most programming languages to calculate boolean expressions faster. For instance in the expression “x() **or** y()” the function y() is never called if x() returns true.

Of course this answer is correct, but this "short-circuit evaluation" is only a special case of lazy evaluation. The program would also work correctly without it. But if we want to define an infinite sequence then we can not use eager evaluation. Let’s look at an example:

// val fibs: seq<int>
let fibs = (1, 1) |> Seq.unfold(fun (n0, n1) -> Some(n0, (n1, n0 + n1)))

We do not need to understand the concrete syntax of this code here. We’ll discuss this later. Let’s just say fibs is bound to an infinite sequence (IEnumerable<int>) of Fibonacci numbers. You could also write this in C#:

/// <summary>
/// Infinite sequence of Fibonacci numbers.
/// </summary>
public static IEnumerable<int> Fibs()
{
var n0 = 1;
var n1 = 1;
while(true)
{
yield return n0;
var t = n1;
n1 = n1 + n0;
n0 = t;
}
}

The trick is IEnumerable evaluates the elements lazy. Only at the time we take an element from the sequence the element will be computed:

fibs
|> Seq.take 10
|> Seq.to_list
|> printfn "%A" // prints [1; 1; 2; 3; 5; 8; 13; 21; 34; 55]

If we would use eager evaluation then “Seq.take” would never been called. But we can go one step further. If we want to get the first 10 even-valued terms in the Fibonacci sequence, we can write this code:

fibs
|> Seq.filter (fun fib -> fib % 2 = 0) // lazy (via pipe)
|> Seq.take 10 // lazy (via pipe)
|> Seq.to_list // eager
|> printfn "%A"
// prints [2; 8; 34; 144; 610; 2584; 10946; 46368; 196418; 832040]

This would be a little bit tricky if we use eager evaluation, but of course this nice laziness comes with some costs for storing intermediate results (and code). So eager evaluation is still often the better choice and sometimes (e.g. *DateTime.Now()*) it makes no sense to use lazy evaluation – at least not if we don’t reevaluate the function.

Tags:

bootcamp,

F#,

Functional Programming
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”

[Wikipedia]

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.

Tags:

.NET Developer Group Braunschweig,

.NET User Group Leipzig,

Currying,

F#,

F-sharp Make,

Fake,

partial application,

pipe,

|>
Last Friday we had a fantastic LearningByTeaching F# BootCamp in Leipzig. Each attendee got homework and had to solve one theoretical question and one programming task. For this two questions they had to present their results to the rest of us and after this I gave my solution in addition.

It was very interesting to see the different strategies and solutions. In this post series I will discuss the questions and some of the possible solutions.

##### Question 1 – What is “Functional Programming” in contrast to “Imperative Programming”?

This seems to be an easy question but in fact, the attendees had some problems to give a short definition of both functional and imperative Programming.

I didn’t find a formal definition of the terms so my intention was to clarify things with an informal description like the one from Wikipedia:

“In computer science, **functional programming** is a programming paradigm that treats computation as the evaluation of mathematical functions and avoids state and mutable data. It emphasizes the application of functions, in contrast to the imperative programming style, which emphasizes changes in state. Functional programming has its roots in the lambda calculus, a formal system developed in the 1930s to investigate function definition, function application, and recursion.”

Wikipedia

I think the main aspect here is: avoiding state and mutable data. Maybe the words “side-effect”, recursion and “higher-order functions” could also be used, but they will be discussed in later questions.

On my slides I covered the following aspects:

- Functional programming is a paradigm
- FP tries to avoid shared state
- Functions are first class citizens, enabling higher-order functions
- Pure functions
- no side-effects
- Results calculated only on the basis of input values
- No information storage
- Deterministic
- ==> Debugging and testing benefits
- ==> Thread-safe without locking of data

For further reading I recommend "Conception, evolution, and application of functional programming languages" (Paul Hudak) or “Functional Programming For The Rest of Us” (Slava Akhmechet).

##### Question 2 – Explain the keyword “let”. In F# we are talking about “let-bindings” and not “variables”. Why?

Basically you use the **let** keyword to bind a name to a value or function. It won’t change any more, so a binding is immutable at default and not “variable”.

I was glad to see the presenter showing the problem with an imperative assignment like

x = x + 1, which from a mathematical view is paradoxical. There is no x which equals x plus one. I think choice of the F# assignment operator is better than equality sign. The statement x <- x + 1 shows the real intention. I want to put the old value of x plus one into the memory cell where x was before.

So we discussed some basic terms like scope and mutability here and I showed how we can explicitly tell the compiler to use mutable data using reference cells or mutable variables.

Maybe it wasn’t that good idea to discuss “Imperative F#” at such an early point (without knowing any functional concepts), but it showed the contrast to immutable let-Bindings.

##### Question 3 – What is a recursion? Try to explain why we often want recursions to be tail-recursive. Hint: Look at the following C# program. What is the problem and how could you solve it?

public static Int64 Factorial(Int64 x)
{
if (x == 0) return 1;
return x*Factorial(x - 1);
}
…
Factorial(10000);

It was interesting to see that nearly nobody expected a real problem in such a short code snippet. Some attendees thought this program might have an integer overflow – but only the presenters (they tested the program) gave the right answer (stack overflow). In fact they gave a very good and deep explanation about recursion and the problem on the stack.

As the question hinted, a possible solution was adding a accumulator variable and using tail-recursion:

public static BigInt FactorialTailRecursive(BigInt x, BigInt acc)
{
if (x == BigInt.Zero) return acc;
return FactorialTailRecursive(x - BigInt.One, x*acc);
}

Unfortunately this "trick" doesn’t work in C# (the compiler doesn’t use tail calls), but it leads to the correct idea – converting it to a while-loop. Of course I would prefer the tail-recursive F# solution:

/// Tail recursive version
let factorial x =
let rec tailRecursiveFactorial x acc =
match x with
| y when y = 0I -> acc
| _ -> tailRecursiveFactorial (x-1I) (acc*x)
tailRecursiveFactorial x 1I

We didn’t cover continuation passing here. I think this could be something for an advanced session.

Next time I will discuss the rest of the introduction and show some of the first programming tasks.

Tags:

F#,

factorial,

Functional Programming,

tail-recursion