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!

Marshaling the Ruby Way

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