Towards FsUnit 1.0

I have been giving a lot of consideration recently to an FsUnit 1.0 release and the direction of the project. The 0.6 release was meant to steer the project more in the direction of Behavioral-Driven Development but there is already a much better project out there for F# and BDD, NaturalSpec.

FsUnit 1.0 will instead be geared for more classical unit-testing and it now has two explicit goals: 1) to make unit-testing with F# more functional in nature and 2) to leverage existing unit-testing frameworks while at the same time exploring new possibilities offered by the F# language.

The target audience for this project is the F# developer (new and veteran alike) who wishes to use the same unit-testing framework that they’re already knowledgeable about: NUnit, MbUnit, xUnit, and MsTest. The new 0.9 release supports only NUnit but the others will be added soon.

The core syntax is pretty much the same as it has always been:

1 |> should equal 1

1 |> should not (equal 2)

[1] |> should contain 1

true |> should be True

But tests are once again contained within a test fixture and executed with a test runner. Here is the code for one of the project examples (UPDATE: removed non-standard use of self-identifier per reader's comments. Thanks, Alan!):

type LightBulb(state) =
    member x.On = state
    override x.ToString() =
        match x.On with
        | true  -> "On"
        | false -> "Off"

[<TestFixture>] 
type ``Given a LightBulb that has had its state set to true`` ()=
    let lightBulb = new LightBulb(true)

    [<Test>] member test.
     ``when I ask whether it is On it answers true.`` ()=
            lightBulb.On |> should be True

    [<Test>] member test.
     ``when I convert it to a string it becomes "On".`` ()=
            string lightBulb |> should equal "On"

[<TestFixture>]
type ``Given a LightBulb that has had its state set to false`` ()=
    let lightBulb = new LightBulb(false)
    
    [<Test>] member test.
     ``when I ask whether it is On it answers false.`` ()=
            lightBulb.On |> should be False
    
    [<Test>] member test.
     ``when I convert it to a string it becomes "Off".`` ()=
            string lightBulb |> should equal "Off"

I’m curious as to what people think about the use of back-ticked method names. I, for one, find it very helpful to be able to write in plain prose instead of CamelCase’d or snake_case’d method names.

Stay tuned to this blog for more information as FsUnit reaches a 1.0 release.

F# and WCF: Data Contracts

F# offers the WCF developer a number of options for defining data contracts. You can use standard classes, constructed classes, or record types to define your data contracts. The key thing to remember is that the DataContractSerializer requires writeable properties. Let's take a look at a simple data contract defined in each of the three ways mentioned.

Standard Types

[<DataContract>]
type MyDataContract =
    val mutable x : string
    
    new() = { x = "" }
    
    [<DataMember>]
    member this.MyDataMember
        with get() = this.x
        and set v = this.x <- v

Constructed Types

[<DataContract>]
type MyDataContract() =
    let mutable x = ""
    
    [<DataMember>]
    member this.MyDataMember
        with get() = x
        and set v = x <- v

Record Types

[<DataContract>]
type MyDataContract =
    { [<DataMember>] mutable MyDataMember : string }

Of the three, I prefer to use record types to define my data contracts. A record type mirrors the intention behind defining a data contract where we are simply declaring a set of data fields by name and type. If you've used the XmlSerializer much, you are probably aware of the default constructor requirement. This restricted the use of record types since they do not get a default constructor. Thankfully, that restriction does not apply with the DataContractSerializer. In addition, you can remove the DataContract and DataMember attributes from your type definition if you are using .NET 3.5 Service Pack 1 although I wouldn't recommend that you do this on a routine basis.

You should use the DataContract attribute to control the namespace and name of your contract. Thus, a good data contract in F# would look something like this:

[<DataContract(
    Namespace = "http://schemas.vernagus.blogspot.com/01/2009",
    Name = "MyDataContract")>]
type MyDataContract =
    { [<DataMember>] mutable MyDataMember : string }

When we create an instance of our contract and serialize it, we get the following:

<MyDataContract xmlns="http://schemas.vernagus.blogspot.com/01/2009"
                xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
  <MyDataMember>my value</MyDataMember>
</MyDataContract>

In my next post I will explore more advanced data contract concepts like collections and enumerations.

F# and WCF Examples

Ted Neward recently wrote about using F# to write WCF services. I share his enthusiasm; so much so that I'm using F# to write examples as I study for MCTS 70-503.

Good examples are hard to find. Most of the time books will give incomplete, or worse, erroneous examples. I have striven to boil each example down to just the essentials needed to get it to run. The examples use F# Interactive and each example is a fully encapsulated, self-sufficient demonstration of some WCF concept. To run an example, simply type fsi --exec <script name>. You can see my examples here: http://code.google.com/p/wcf-examples/source/browse/#svn/trunk/FSharpExamples

I am planning to run a series of posts based on my experience in using F# to write WCF services. Stay tuned for that!

Programming with State in F# (Part 2)

In my last post, I talked about the contrast between F# where state is locked by default and your run-of-the-mill imperative language where it is very difficult to lock state. We also saw that F# allows us to explicitly use mutable state when we choose to do so but the point is that programmer must make an explicit choice. The theme of this series of posts is that F#'s answer to the "whether to use state or not to use state" question is the best: we try not to use state where we can get away with it but when we have to use state we make that decision explicitly and carefully.

I just want to talk about one example from the F# Core library. Here is an example from the Seq module:

let length (ie : seq<'a>)    = 
    use e = ie.GetEnumerator() 
    let mutable state = 0 
    while e.MoveNext() do
        state <-  state + 1;
    state

The length function takes any sequence and returns an int. The first line of the function retrieves the enumerator for the sequence. The second line declares a mutable identifier clearly labeled state. The rest of the function simply moves through the enumerator incrementing the count. Finally, the function returns the final count. Do the internals of the length function surprise you? This example is very similar to how a length might be determined in an imperative context and it highlights my favorite feature of F#: it's your choice. You certainly can implement length with a recursive function and an accumulating value but would it be as fast as the version shown above? Would it be as easy to understand? You decide.

Choices abound when using F# and one of the most important choices you can make will be whether or not to use state. The point of these last two posts are to highlight this quality of F#. State is generally discouraged but it is always available should you choose to use it.

Programming with State in F# (Part 1)

There is frequent talk these days about the use of state in programs--how to limit it and whether it should be used at all. The rising importance of concurrency and functional languages have a lot to do with this but state is hardly going to go away any time soon. For instance, Kent Beck writes favorably about state in his recent book, Implementation Patterns:

I think state is a valuable metaphor for us since our brains are structured and conditioned to deal with changing state. Single assignment or variableless programming forces us to discard too many effective thinking strategies to be an attractive choice.

Kent goes on to show his readers a set of patterns that can be used to manage and communicate state in a safe and effective manner. I agree that state is a valuable metaphor in programming but what is a programmer to do if they also see value in single assignment or "stateless" programming? I think F# offers the most compelling answer to this question and I'll explain why.

You declare a value in F# with the let keyword:

> let x = 1;;

val x : int

We can later retrieve the value, 1, using our identifier, x:

> x;;

val it : int = 1

Suppose, however, that we wanted to change the value assigned to x. We would use the assignment operator like so:

> x <- 2;;

  x <- 2;;
  ^^^^^^^

stdin(13,1): error FS0027: This value is not mutable.

As you can see, identifiers are immutable by default in F#. Once declared, they cannot be changed. This behavior extends to more complex value types. Consider this example:

> open System.Drawing;;
> let p1 = new Point(0,0);;

val p1 : Point

> p1.X <- 1;;

  p1.X <- 1;;
  ^^^

stdin(24,1): error FS0191: A value must be local and mutable in order to mutate
the contents of a value type, e.g. 'let mutable x = ...'.

Even though the X property of System.Drawing.Point is settable, F# treats our Point as if it is immutable. We can see how the default behavior of F# compels the programmer to limit his use of state; that's just the way that it should be. By contrast, it takes a lot of forethought to limit state in an imperative language.

You can opt-in to the use of state by using the mutable keyword:

> let mutable p2 = new Point(0,0);;

val mutable p2 : Point

> p2.X;;

val it : int = 0

> p2.X <- 1;;

val it : unit = ()

> p2.X;;

val it : int = 1

When you declare an identifier as mutable, you get a variable just like you may be used to in C# or Visual Basic. You can even change the reference entirely:

> p2 <- new Point(1,1);;

val it : unit = ()

> p2;;

val it : Point = {X=1,Y=1} {IsEmpty = false;
                            X = 1;
                            Y = 1;}

To conclude this post, I hope to have shown some very basic examples of how F# forces you to think about where you are using state and why. This is a very good thing and in my next post, we will explore the use of state in functions and types.

Book Samples in F#

I'm fairly new to functional programming but I am on my second reading of a couple of great titles: The Little MLer and Purely Functional Data Structures.

Both of these books contain code samples in Standard ML (SML) (the latter contains a Haskell appendix). Readers with a background in functional languages would have no problem translating from SML to OCaml and F# but for newcomers this can be a very complicated endeavor and it greatly detracts from the reading.

When I first read these books I failed to find any code examples in F# and I even struggled to find OCaml samples based on the books. In order to encourage newcomers to F# to take up a study of functional programming, I have started a project on Google Code to address this need. The project will host relative ports of code samples from various books.

I do not intend for the ports to be literal translations. There are, for instance, constructs in SML that simply aren't available in F#. But the samples should convey the spirit of the book even if they use different means to achieve that end.

If you have samples or suggestions, corrections, or improvements for the samples, please get in touch!

FsUnit 0.6.0

I've just wrapped up a 0.6.0 release of the FsUnit specification framework for F#! I'm really starting to appreciate the benefits of writing specifications or tests in a functional language. I hope that this project convinces others in the same way.

The F# 1.9.6.0 release is a very important release. F# developers get much deeper support in Visual Studio, for one, and this led a complete overhaul of the tests behind FsUnit. I prefer to do test-driven development when I can, thus a rewrite of the tests meant a rewrite of the framework itself. Everything ended up pretty much the same as it was in the previous release (0.5.0) with a couple of minor changes.

The first important change was better messages with failures and errors. The previous release didn't always provide informative messages. With this release, you should always receive enough information to identify the problem.

The second important change involves better support for exceptions that may occur when running your specs. Exceptions should not prevent any other specification from running and should one occur, you should get a full stack trace along with the exception message.

Finally, there was a slight change to the spec function. Use of spec still evaluates your specification, but it no longer adds it to the internal mutable results collection. I wanted to leave mutable state out of the framework wherever possible, thus, spec now returns a string * Result pair and programmers can choose to use or not to use state in their specifications. If you're lazy like me, you can use the specs function to have FsUnit track your results for you.

See the project home page, the project wiki, or the included examples for more information about the project. Please check it out and let me know how I can make it better!

Get Going Quickly with F# and ASP.NET MVC

Want a quick way to get going with F# and ASP.NET MVC?

1. Start a new MVC project.
2. Add an F# project to your solution with a source file in it.
3. Set the project type for your F# project to dll.
4. Set the output path to the bin folder of your MVC project.
5. Add a namespace declaration to your F# source file. The namespace must match your MVC project's namespace, for example, MvcApplication1.Controllers.
6. Write a controller in F# and compile your F# project.
7. Reference your F# output in your MVC project.

If everything's wired up correctly, you can visit the appropriate URL in your browser and your F# controller will get called!

FsUnit 0.5.0!

I'd like to announce the release of FsUnit 0.5.0! What began as a stabilization release ended up as a complete rewrite. The core syntax is still the same, in fact, it got even better. One of the primary goals of FsUnit is to remain as clean as possible, from language constructs that is.

This latest release actually removed the need for a pair of parens in many cases. So instead of:

1 |> should (equal 1)

you can now write:

1 |> should equal 1

Getting rid of parens at this level is pretty important to me so it's pleasure to bid them adieu!

One of the other major changes was perhaps more for my sake than for the user's but then maybe not. Prior releases incorporated negation into the assertion bit itself. So if you wanted to say "1 should not equal 2" you had to write:

1 |> should (notEqual 2)

The not' keyword makes it possible to negate any assertion in FsUnit:

1 |> should not' (equal 2)

This removed a lot of duplicate code and it also just about cut the number of specs for FsUnit itself in half.

Finally, the last major change is the spec keyword. This keyword is a shortcut for labeling and executing your specs. It also stores the result in a ResultStore object. With the spec keyword, specs look like this:

spec "A number should equal itself."
  (1 |> should equal 1)

I like the way that this looks very much and I'm going to try to keep this syntax stable between releases.

Let me know what you think of the new release!

Using LINQ with ArcObjects

Are you using .NET 3.5 to do ArcObjects programming? Are you still manually enumerating through row or feature cursors? Listen up!

It's really very simple to get LINQ running with ArcObjects. All you have to do is add an extension method to either ICursor or IFeatureCursor like so:

public static class ICursorExtensions {

    public static IEnumerable<IRow> AsEnumerable(this ICursor source) {
        Func<IRow> next = () => source.NextRow();
        IRow current = next();
        while (current != null) {
            yield return current;
            current = next();
        } 
    }
}

With your new extension method in hand, you can unleash LINQ on your ArcObjects code. You can now write code like this:

Int32 count = cursor.AsEnumerable().Count();

Or, you could write a query expression against two cursor objects:

var resultSeq =
    from x in cursor1.AsEnumerable()
    from y in cursor2.AsEnumerable()
    where x.get_Value(0) = y.get_Value(0)
    select new { Left = x, Right = y };

You can do a similar thing in F#:

type ICursor with
    member c.AsEnumerable() =
        seq { 
            let next = c.NextRow
            let current = ref (next())
            while !current <> null do
                yield !current
                do current := next()
        }
let count = cursor.AsEnumerable() |> Seq.length

Sure beats manually manipulating an enumerator, doesn't it?

Kill That Annoying Flicker

The DataSamples sample (pp. 291-303) in Expert F# has an annoying flicker that can be fixed by adding the following line of code after line 101:

do base.SetStyle(ControlStyles.AllPaintingInWmPaint |||
                 ControlStyles.UserPaint |||
                 ControlStyles.DoubleBuffer,
                 true)

If you're writing the code yourself, put the above line after this line:

do base.BackColor <- Color.DarkBlue 

Purely Functional Data Structures: An F# Binary Tree

Continuing my series on Purely Functional Data Structures, here's my F# implementation of a binary tree:

#light

type Elem = int

type Tree = E | T of Tree * Elem * Tree

let empty = E

let rec mem = function
    | x, E -> false
    | x, T(a, y, b) when x < y -> mem(x, a)
    | x, T(a, y, b) when y < x -> mem(x, b)
    | _ -> true

let rec insert = function
    | x, E -> T(E, x, E)
    | x, T(a, y, b) when x < y -> T(insert(x, a), y, b)
    | x, T(a, y, b) when y < x -> T(a, y, insert(x, b))
    | _, s -> s

Here's what the tree looks like in use:

> let t = T(E, 1, E);;

val t : Tree

> t;;

val it : Tree = T (E,1,E)

> let t1 = insert(0, t);;

val t1 : Tree

> t1;;

val it : Tree = T (T (E,0,E),1,E)

> let t2 = insert(10, t1);;

val t2 : Tree

> t2;;

val it : Tree = T (T (E,0,E),1,T (E,10,E))

> let t3 = insert(5, t2);;

val t3 : Tree

> t3;;

val it : Tree = T (T (E,0,E),1,T (T (E,5,E),10,E))

> mem(10, t1);;

val it : bool = false

> mem(10, t2);;

val it : bool = true

Stack Examples

Here is the previous stack implementation in use.

> let xs = Cons(0, Cons(1, Cons(2, Nil)));;

val xs : int Stack

> xs;;

val it : int Stack = Cons (0,Cons (1,Cons (2,Nil)))

> let ys = Cons(3, Cons(4, Cons(5, Nil)));;

val ys : int Stack

> ys;;

val it : int Stack = Cons (3,Cons (4,Cons (5,Nil)))

> let zs = xs -||- ys;;

val zs : int Stack

> zs;;

val it : int Stack = Cons (0,Cons (1,Cons (2,Cons (3,Cons (4,Cons (5,Nil))))))

> head xs;;

val it : int = 0

> tail xs;;

val it : int Stack = Cons (1,Cons (2,Nil))

> update(xs, 1, 99);;

val it : int Stack = Cons (0,Cons (99,Cons (2,Nil)))

Purely Functional Data Structures: An F# Stack

One of the beauties of F# is that it doesn't force you to follow one programming technique. If you want to code with objects in an imperative style, you're free to. If you want to write strict functional code, you're free to do that as well.

I'm quite familiar with imperative modes of programming so I've been bending my mind in the functional direction by reading Purely Functional Data Structures. The book's examples are written in ML (with a Haskell appendix), so I'm re-writing them in F#. I'll post them here as I do in the hopes that it will help other .NET programmers bend their mind as well.

Here is the code for a Stack implementation from Chapter 2.1:

#light

exception Empty
exception Subscript

type 'a Stack = Nil | Cons of 'a * 'a Stack

let empty = Nil

let isEmpty = function
    | Nil -> true
    | _ -> false

let head = function
    | Nil -> raise Empty
    | Cons(x, s) -> x
    
let tail = function
    | Nil -> raise Empty
    | Cons(x, s) -> s

let rec (-||-) xs ys =
    if isEmpty xs then
        ys
    else
        Cons(head xs, tail xs -||- ys)

let rec update = function
    | Nil, i, y -> raise Subscript
    | xs, 0, y -> Cons(y, tail(xs))
    | xs, i, y -> Cons(head(xs), update(tail(xs), i-1, y))

F# and ArcObjects

Interested in programming with ArcObject using F#? It's easy!

Start fsi referencing the appropriate ArcObjects assemblies:

C:\>fsi -I C:\ArcGis\DotNet -r ESRI.ArcGIS.System.dll -r ESRI.ArcGIS.DataSourcesGDB.dll -r ESRI.ArcGIS.Geodatabase.dll

Now you can open some ArcObjects namespaces:

> open ESRI.ArcGIS.esriSystem;;

> open ESRI.ArcGIS.DataSourcesGDB;;

> open ESRI.ArcGIS.Geodatabase;;

Next, we need to initialize our license:

> let aoi = new AoInitializeClass();;

val aoi : AoInitializeClass

> aoi.Initialize(esriLicenseProductCode.esriLicenseProductCodeArcView);;

val it : esriLicenseStatus = esriLicenseCheckedOut

Then we can connect to our geodatabase:

> let workspaceString = "user=MyUserName;password=MyPassword;server=MyServer;instance=MyInstance;version=SDE.DEFAULT";;

val workspaceString : string

> let fact = new SdeWorkspaceFactoryClass();;

val fact : SdeWorkspaceFactoryClass

> let ws = fact.OpenFromString(workspaceString, 0);;

val ws : IWorkspace

> let featureWs = (box ws) :?> IFeatureWorkspace;;

val featureWs : IFeatureWorkspace

Notice that we have to first box our Workspace object before we can cast it to the IFeatureWorkspace interface. I believe that this has to do with explicit member implementation, but I could be wrong.

Want to get a specific feature? OK:

> let fc = featureWs.OpenFeatureClass("MyFeatureClass");;

val fc : IFeatureClass

> fc.GetFeature(1684597);;

val it : IFeature = System.__ComObject

And so on...

As you can see, F# has no problem working with ArcObjects. Throw in the Interactive Console and you have a very attractive platform for programming with ArcObjects.

Easy Testing in F#

I've found a personally acceptable answer to the debate about whether or not to test private members. This is a technique that you can use in F#.

Here are some of the issues that you might face in testing F# code:

• I want to keep my test code out of my production assembly.
  
• I need a CLS-friendly API that doesn't expose F#-specific types.
• I want to test at as fine-grained a level as I can.
  

Perhaps you see my quandary. I want my test code to be in a separate assembly from my production code, so the code-under-test needs to be exposed. The more CLS-friendly I make my assembly, the further away from the code I get. And finally, I want to test all of those little functions that I'll inevitably end up writing except I don't want to expose all of those little functions in my API.

My answer? It's simple, I just compile my SUT without including my interface (.fsi) file! When you do this, every value declared in your source (.fs) file is exposed to the world for testing. Then, when I compile for release, I include the interface file and all of that stuff is hidden.

Thus far, I've found no issues with NUnit working in this manner and it's given me the Best of Both Worlds as far as test coverage and CLS-friendly API's go!

FsUnit

I've really been getting into F# as of late. I love not having to declare types everywhere. The syntax is almost as beautiful as Ruby. I've had no problems interoperating with any other .NET library. This latter point was a particular breath of fresh air; I don't, for example, like how IronPython handles interfaces.

It's a struggle to learn functional programming concepts at the same as you learn a new language but that's why I chose F# in the first place. :) It's not that bad actually since with F# you can code in the same manner as you would in Visual Basic or C#. It really lets you ease into the whole functional thing...you never feel forced into something you're not ready for which is a danger when learning a purely functional language like Haskell (which I also like very much).

So the first thing I learn in a new language is a good testing framework. I love me some NUnit just as much as the next guy, but I prefer the syntax of RSpec. I'm working on a happy medium in a project that I'm calling FsUnit. You can get it here.

With FsUnit, you still write TestFixtures and Tests but you can write assertions like the following:

1 |> should equal 1

or

true |> should be True

Please try it out, send me ideas or corrections, and otherwise, enjoy yourself testing in F#! :)