Consumed by Code

Towards FsUnit 1.0

2009-12-14T22:29:00.005-05:00

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

2009-01-26T10:24:00.005-05:00

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

2009-01-19T07:58:00.004-05:00

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)

2008-09-18T07:53:00.009-04:00

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)

2008-09-17T09:47:00.007-04:00

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#

2008-09-08T21:07:00.007-04:00

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

2008-09-04T09:05:00.003-04:00

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!

Marshaling the Ruby Way

2008-08-29T14:07:00.006-04:00

This post is for the .NET developer who is looking at IronRuby but is otherwise unfamiliar with Ruby. As you learn Ruby, keep in mind a question that Ruby programmers like to ask themselves a lot, "What is the Ruby Way of solving this problem?" Today the problem is marshaling an object and we're going to solve it the Ruby Way.

If you're like most other .NET developers, you're probably thinking about BinaryFormatters or perhaps you prefer XmlSerializers. Maybe you're thinking about DeserializationCallbacks or XmlIgnoreAttributes and where to put them. Stop right there! That's definitely not the Ruby Way.

Let's define a Ruby class:

class Person
  attr_reader :first_name, :last_name, :hobbies
  
  def initialize(first_name, last_name, *hobbies)
    @first_name = first_name
    @last_name = last_name
    @hobbies = hobbies
  end
end

This is just a simple class with three read-only attributes: first_name, last_name, and hobbies. How would we create an instance of our class and marshal it the Ruby Way?

ray = Person.new("Ray", "Vernagus", "programming", "walking")
yml = ray.to_yaml
puts yml

to_yaml, what's that? YAML stands for "YAML ain't markup language." Did that make you smile? Now that's the Ruby Way! ;) YAML is very simple but also very powerful. It's the kind of notation that you would write yourself if you were just jotting a class down on a piece of paper except that it's structured and standardized. Here's what our marshaled person looks like:

--- !ruby/object:Person
first_name: Ray
hobbies: 
- programming
- walking
last_name: Vernagus

Not bad, aye? That's about as ugly as you're likely to see YAML get. I encourage you to learn more about YAML and to use it in place of XML every chance that you get.

We can get our person back just as easily:

p = YAML.load(yml)
puts p.inspect

and this prints:

#<Person:0x0000064 @first_name="Ray", @hobbies=["programming", "walking"], @last_name="Vernagus">

This is all running in IronRuby (batteries-included version).

Threading in IronRuby (Part 2)

2008-08-27T20:43:00.003-04:00

In my last post I pointed out some issues with the Thread.new construct in IronRuby. One of the advantages of using IronRuby is that we have access to the .NET framework. In this post, we'll take a look at using the ThreadPool class in order to correct some of the issues that came up in the previous post.

The first issue that we saw with the Thread.new construct was that it launched the thread as soon as we declared it. When using the ThreadPool, we first declare a callback object:

require "mscorlib"
include System::Threading

callback = WaitCallback.new { puts "pool thread" }

We declare a callback in a similar manner to a Thread, by passing a block to the constructor. In this case, however, we get a WaitCallback object that we can hold on to until we are ready to execute the block. You can run the code block by queuing it up in the ThreadPool:

ThreadPool.queue_user_work_item callback

You may need to pause the main thread in order to see the line print to the console, giving us this as a full example:

require "mscorlib"
include System::Threading

callback = WaitCallback.new { puts "pool thread" }
ThreadPool.queue_user_work_item callback

Thread.sleep 100

The other issue that I mentioned concerning the Thread.new construct was that it defaulted to a foreground thread. This isn't a problem when using the ThreadPool since all ThreadPool threads are background threads.

A lot of this code is very un-Ruby-like. For instance, it would be nice to just write:

ThreadPool.queue_user_work_item { puts "pool thread" }

Hopefully future versions of IronRuby will make it easier to pass blocks in place of delegates. That would definitely make these tasks feel more like Ruby.

Threading in IronRuby (Part 1)

2008-08-25T21:32:00.005-04:00

I couldn't find much at all on the Web about threading in IronRuby. Here's a little introduction to some basic threading in IronRuby.

In contrast to Ruby's less than ideal threading model (which is to change in 1.9), .NET has a rich threading model that we can tap into using IronRuby. We can create a new thread in IronRuby in the same way that we do in MRI Ruby:

Thread.new { puts "child thread" }

In IronRuby, however, we're not talking "green" threads. Instead, we get a real .NET thread as demonstrated in this example:

require "mscorlib"
include System::Threading

puts "##{Thread.current_thread.managed_thread_id} is the main thread."
# #1 is the main thread.

Thread.new { puts "##{Thread.current_thread.managed_thread_id} is a child thread." }
# #3 is a child thread.

You may have noticed that we didn't have to do anything to launch the thread. This is undesirable if you need to, for instance, start a thread as a background thread. Since the default value for the IsBackground property is false, the thread in the example above runs as a foreground thread. If your thread runs long enough, you can do this:

require "mscorlib"
include System::Threading

t = Thread.new { Thread.sleep 1000 }
puts "t.is_background = #{t.is_background}"
# t.is_background = false

t.is_background = true
puts "t.is_background = #{t.is_background}"
# t.is_background = true

Use of Thread.new will probably suffice in only the simplest situations. IronRuby supports more advanced threading scenarios and we'll get started on that in the next post in this series!

Get Going Quickly with F# and ASP.NET MVC

2008-08-09T21:05:00.003-04:00

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

Start a new MVC project.
Add an F# project to your solution with a source file in it.
Set the project type for your F# project to dll.
Set the output path to the bin folder of your MVC project.
Add a namespace declaration to your F# source file. The namespace must match your MVC project's namespace, for example, MvcApplication1.Controllers.
Write a controller in F# and compile your F# project.
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!

ASP.NET MVC & REST

2008-08-06T14:37:00.003-04:00

Make that 4 too many acronyms...my apologies.

I'm crazy about REST. It appeals to me in a number of ways and it's the primary reason behind my interest in ASP.NET MVC. I didn't know a thing about REST prior to Ruby on Rails v2.0 but then again I wasn't a web programmer prior to that. Now that I'm building web applications on a regular basis, I've been drawn to REST and Rails concepts.

Which brings me to the topic of this post: REST on ASP.NET MVC (MSMVC)! It turns out that the MSMVC framework is very capable of following REST principles. The routing engine supports constraints based on HTTP methods and it's a no-brainer to also support overloaded POST. Here's a simple constraint to support a hidden _method form input:

public class FormMethodConstraint : IRouteConstraint {
    string _method;

    public FormMethodConstraint(string method) {
        if (String.IsNullOrEmpty(method))
            throw new ArgumentException("method cannot be null or empty.", "method");
        _method = String.Format("^{0}$", method);
    }

    public bool Match(System.Web.HttpContextBase httpContext,
            Route route, string parameterName,
            RouteValueDictionary values,
            RouteDirection routeDirection) {
        var vals = httpContext.Request.Form.GetValues("_method");
        if (vals == null) return false;

        foreach (var val in vals)
            if (Regex.IsMatch(val, _method, RegexOptions.IgnoreCase)) return true;
        return false;
    }
}

With this class, you can write routes that support overloaded POST:

source.MapRoute(
    "FormDestroy",
    "{controller}/{id}",
    new { action = "Destroy" },
    new { httpMethod = new HttpMethodConstraint("POST"),
          formMethod = new FormMethodConstraint("DELETE") }
);

Now, you can put a hidden input in your form with the name _method and the value DELETE and when the form is sent back the server, it will route to the Destroy() action on your controller!

There's more RESTful goodness to come from me, I'm just getting started! :)

GIS Server REST and Quirks Mode

2008-07-25T22:50:00.007-04:00

ESRI recently released their REST API for GIS Server. I finally got a chance to put the REST API to use today and I have to say that I love it thus far! This really changes the picture for developing web apps using GIS Server.

I did, however, notice that the javascript examples produced by the REST services aren't XHTML. This has the side effect of forcing the browser into quirks mode. You can see why this was likely intended by adding a DOCTYPE declaration to the top of one of the sample pages:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

When you do this, the map disappears! The sample pages use a table layout with style="height: 99%;" to expand the table row to fill the page. The problem with this approach is that it is only supported in quirks mode.

I'm not an expert on CSS but I am able to get a map to fill the page without using a table layout or quirks mode. You should be able to just add this style declaration in the <head> section of your page:

<style>
   html, body, div#map {
       height: 99%;
   }
   body {
       margin: 0px; /* Used here for IE & Mozilla */
       padding: 0px; /* Used here for Opera */
   }
   div#map {
       width: 99%;
   }
</style>

Using this approach, you don't have to embed your maps in a table layout and you can write true XHTML.

FsUnit 0.5.0!

2008-07-24T10:12:00.004-04:00

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

2008-07-22T09:52:00.001-04:00

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?

Unit Testing in Functional Languages

2008-07-21T21:41:00.000-04:00

I'm very interested in learning more about how people are doing unit-testing in functional languages. My personal experience has been with OUnit and HUnit for OCaml and Haskell respectively. These frameworks get the job done but they felt foreign to me when I was using them.

Perhaps my feeling stemmed from an unfamiliarity with functional programming in general but I think it had more to do with the fact that these frameworks were trying to be just another xUnit. (Not XUnit but xUnit.) There's definitely a benefit to be had in reusing things that are already well-known but I think this gives short shrift to functional programs.

My current thoughts on the matter are ultimately being expressed in the FsUnit project where I plan to bring inspiration from my favorite frameworks. RSpec is probably at the top of the list which is apparent in my choice of keywords.

Functional programming is a perfect fit for unit testing: no side-effects; small, composable units; deterministic paths; idempotence. These are some of the most important qualities of programs that make them testable. Add to that a deep support for language-oriented programming and we have fertile ground for test-driven development and the likes.

If you have experience unit testing in functional languages, I would love to get example code and/or resources.

Terrarium 2 & F#

2008-07-20T14:54:00.001-04:00

The Terrarium project was recently updated and added to Codeplex as Terrarium 2. I attempted to run through the tutorial that comes with the SDK using F#. I did so with some trepidation because the "What is Terrarium" document warns us that support for other .NET languages is conditional on certain security features that are enforced by Terrarium. Some of the things that are disallowed by Terrarium are static methods, threading calls, and deconstructors.

I had no luck getting the tutorial to run in F#. I always end up with either an exception on birth or a security violation. I was, however, able to get an F# creature to appear in my Terrarium after I stripped it down to just a shell of an Animal. But that's not very interesting is it?

More to come on this as language support improves (something the SDK mentions will get better)!

Kill That Annoying Flicker

2008-07-16T21:29:00.000-04:00

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

2007-10-14T09:00:00.000-04:00

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

2007-10-13T23:09:00.001-04:00

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

2007-10-13T22:31:00.000-04:00

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

Extension Methods and IronRuby

2007-10-02T12:36:00.000-04:00

You may or may not be excited about C# getting extension methods but this idea is a core part of Ruby. IronRuby carries this spirit into .NET where it's a simple matter to add a method to an existing class--even a BCL class.

As rich as the BCL classes are, there are times where a bit of functionality is just plain missing. In sticking with true object-oriented practices, Ruby makes it easy to add that functionality where it belongs.

Suppose that you are constantly turning your strings into questions. Instead of creating a Questionizer class that takes a string and manipulates it in some way, wouldn't it be nice to just store our questionizing functionality on the strings themselves? Enter the IronRuby prompt and type the following:

>>> class String
...   def questionize
...     self + ", eh?"
...   end
... end
=> nil

You just added a method to all String objects. Now you can use your method anywhere that you have a string object:

>>> "Nice weather".questionize
=> "Nice weather, eh?"

Now go forth and put your functionality where it clearly belongs!

Functional Programming Patterns

2007-09-25T13:58:00.001-04:00

If you're new to functional programming (like me), you'll quickly find a number of useful patterns that you can apply to your everyday coding tasks. Take the following task as an example: we have a FeatureCursor and we would like to repeat a certain action for every Feature in the Cursor. In C#, it would look something like this:

IFeature feature = cursor.NextFeature();
while (feature != null)
{
    // Do something with the feature
    Console.WriteLine(feature.OID);
    feature = cursor.NextFeature();
}

This is a common pattern in ArcObjects. How can we express this pattern in F# while allowing for flexibility in the action that we wish to perform?

let forAll (f : IFeature -> unit) (cursor : IFeatureCursor) =
    let mutable feature = cursor.NextFeature()
    while feature <> null do
        // Do something with the feature
        f feature
        feature <- cursor.NextFeature()

We can pass any function that we want to so long as it takes an IFeature and returns unit:

forAll (fun feature -> Console.WriteLine(feature.OID)) cursor

You could write a ForAll function in C# but it just wouldn't feel as natural, would it?

F# and ArcObjects

2007-09-25T13:10:00.001-04:00

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#

2007-09-20T18:20:00.000-04:00

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!

IronRuby Tests

2007-07-23T20:44:00.000-04:00

I'm sure there's a lot to be learned from the IronRuby code base but one thing in particular stuck out in my mind: the test code is actually good Ruby code.

This was in stark contrast to the Ruby.NET test code which looks more like LISP to me than Ruby. Don't get me wrong, there's a lot to impress the Ruby enthusiast in the Ruby.NET project especially since it has been moved to an open source contribution model.

My point is simply that I have confidence that IronRuby will be true to the Ruby spirit. For one, they allow for Ruby-casing when calling .NET classes, e.g., Environment.user_name instead of Environment.UserName. For another, they've obviously been studying RSpec (this is a good thing!). This is the kind of code that I like to see behind anything that I use:

describe "range creation" do

 it "creates an inclusive range object from integer literals" do
    a = 0..1
    a.class.name.should == "Range"
    a.begin.should == 0
    a.end.should == 1
    a.exclude_end?.should == false
 end

end

The IronRuby test suite would be a great model for the various Ruby specification projects that are out there. It's a from-the-ground-up, behavioral specification for any Ruby language implementation.

It's an exciting time for Ruby programmers who have (or want) to use .NET!

IronRuby & C# Express

2007-07-23T20:41:00.000-04:00

Microsoft won my heart today by releasing IronRuby and by announcing that it will indeed be taking outside contributions.

As if this weren't enough, I was able to build the entire IronRuby project with C# Express Edition. This isn't something that can be done with the Ruby.NET project.

It's because of things like this that I've been spending less and less time in Linux lately...

FsUnit

2007-07-23T20:17:00.000-04:00

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

true |> should be True

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

Mocking ArcObjects

2007-02-02T10:11:00.000-05:00

I'm an avid test-driven developer but I'm also an ArcObjects programmer. Do you think this is an oxymoron? Read on!

Yes, ArcObjects are very expensive to create. Yes, they are slow and consume a lot of infrastructure. But none of this matters. ESRI did test-driven developers a humongous favor when they took an interface-oriented approach to ArcObjects. By doing this, they enabled us to easily unit test our code.

Suppose you are about to write a simple C# method like the following. How do we set up a test for it?

public static void EditFeature(IFeature feature, string fieldName, object value)
{
     feature.set_Value(feature.Fields.FindField(fieldName), value);
}

Simple enough, right? Wrong! To even get a IFeature, we have to create am IFeatureWorkspace and to get one of those we'll have to create an IWorkspaceFactory. If your setup is anything like mine, that'll take tens of seconds and even minutes. Local geodatabases would ease that pain but either way our test will not be a unit test.

Do not despair! There's a way to test our method without relying on anything external to that one line of code. There's a wonderful testing tool called mock objects and with them we can test that our ArcObjects code does exactly what we want it to do.

You can go here if you want to learn more about mock objects. Today I'm just here to introduce you to a simple example of using mock objects to test ArcObjects code.

My favorite mocking framework for .NET is Rhino Mocks. When we want to create mock objects using Rhino Mocks, our first step is usually to create a MockRepository:

MockRepository mocks = new MockRepository();

The next thing that we need to is create our mock objects:

IFeature mockFeature = mocks.CreateMock();
IFields mockFields = mocks.CreateMock();

I'll explain why we need to create a mock IFields object in a second. Once you have your mock objects, you can start setting up your expectations. In Rhink Mocks, this works a bit like the record button on your...well, what has a record button these days? Take another look at the method that we're testing. We set the Value of an IFeature by giving it the index of the field that we want to change. This expectation is expressed like so:

Expect.Call(mockFields.FindField("field")).Return(1);

This line tells our MockRepository to expect our code under test to call the FindField() method on the mockFields object. It also demands that the value passed in to the method has to bed "field". Finally, we return the value 1 when that method is called.

Our next expectation is that the value returned by FindField() is used to set the value of the field. This expectation states that we expect the field at index 1 to be set to the value, "value":

mockFeature.set_Value(1, "value");

The last thing that we need to do is to tell our mockFeature to return our mockFields whenever its Fields property is called:

SetupResult.For(mockFeature.Fields).Return(mockFields);

That's it! Let's tell our Mock Repository that we're done setting up our expectations:

mocks.ReplayAll();

We really just have one line of test code:

EditFeature(mockFeature, "field", "value");

If we did all of this correctly, our test will pass and we have just written an ArcObject method test-first.