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,
|>