Saturday, October 25, 2008

Test faster with Tools

With the release of TestDriven.Net version 2.16, you can now run your F# unit tests within Visual Studio. Prior to this version, I would execute my unit tests via NUnit-Gui, or xUnit's command line utility. Both tools are wonderful for handling unit tests, but like most, if not all programmers, I am lazy. I was getting very tired of switching windows. I even wrote my own small testing harness, here but I still had to fuss around with switching windows.

I do realize that all it took was a simple keystroke combination of alt-tab, but waiting for my machine to re-paint the windows and the tools to re-load the new assembly became tiresome. To add to my laziness, in order to run my tests when in C#-ville, I assigned keystokes TestDriven.Net run tests method, I didn't even have to use the mouse! Resharper is another tool I use when I am programming in C#-ville, although Resharper has not yet made it way in to the F# world, there are still parts of the tool you can use. Consider the blank F# page, when you start a new project. All you get is:

#light

Not much here to get you started. So I created a ReSharper Live Template called "fixturef".

When I press the tab key, I get the following:

Viola! I don't have to type any of the setup structure to get my base Test Fixture!

Wait, there's more!

I also created another ReSharper Live Template, called "ftest":

When I press tab:

Viola! All I have to do at this point is type the rest of my test methods name.

By now, I know you're now asking yourself, "it can't possibly get any lazier", but oh yes, it can!

When I actually have to type some code to get a unit test ready to run, I got tired of having to reach the 10 inches for my mouse and perform a series of point-and-click operations. TestDriven.Net provides commands that you can assign keyboard shortcuts to. In Visual Studio, go to the options screen and select Keyboard. In the command name text box, start typing TestDriven. There are a series of commands to invoke TestDriven.Net. I assigned the ctl-alt-shift-T keystroke to the TestDriven.Net.RunTests command.

So now when I have a test to run, I can press ctl-alt-shift-t and invoke TestDriven to run my tests. No more window switching, or mouse-clicking!

You get a nice message in the status bar of Visual Studio, letting you know the status of your test run.

Oops, one test failed, all I have to do is use the ctl-tab keys to switch between documents in Visual Studio and I see the results of my tests in the Output window.

Enjoy my laziness!

Thursday, July 24, 2008

Wow – What a trip. F#, C#, TDD, COBOL and enlightenment

Life truly has a fantastic humbling ability. A few months ago I was in the midst of a deep dive, swimming in the goodness of F#. I had all sorts of wonderful ideas on future blog posts. I was treading in a veritable pool of functions, records, pattern matching, currying; all while not getting bogged down in semi-colons and missing curly brackets! I was on top of the world.

Then life reminds you what is truly important, my wife and I were blessed with our 3rd child at the end of May. What a wonderful addition to our family. So after one month of anxiety waiting for the baby to arrive and then another two months of interrupted sleep, burping, changing diapers and worrying about poop, (those of you with kids understand!) my thoughts never strayed too far the pool. So here I go, with a great big cannonball, I splash back into the blog waters. It was during those few months out of the pool, when my only concentration on coding was in C#-ville from 9 to 5, several statements of a profound nature crept into my head. I have been long since spoiled on the benefits of Test Driven Development (TDD); write a test, write some code, make the test pass, refactor, run tests - beautiful simplicity.

As simple as that is, one of my co-workers would always write extra code; code that was not needed to make the tests pass. He could not bring himself to just write the simple code that made the test pass. I would always ask the question, why did you write that? The test would still pass if that block was not there.

His reply was always, "We'll need it soon." Rather than argue, because he would be right, and delete the code he had written, we would go on our way and complete the task at hand. (By the way, when teaching TDD to someone new, deleting code that has no coverage is a great way to enforce the rule that you shouldn't write any code that is not a result of a test!)

So one day, our group was having a small discussion while taking a break from coding and talking about past jobs and different languages we knew. This guy mentioned he programmed COBOL for several years prior to migrating to java and C#. While I snickered and mentioned my own experience with COBOL; a mere two semesters in college and a professor that couldn't code, he laughed and said, "you had to be careful about your code, if you had a bug, you could crash the entire system for everyone". So after my casual chuckling, I repeated his statement and added something to the effect of, "wow, I would have surly pissed of a lot of other developers, my code is always buggy, I rely on tests to find them, not the final run." As soon as I said that, the little light switch in my head clicked and I then realized why our coding styles were so different, why he just couldn't write the simple code and trust the tests.

Being faced with the situation of crashing an entire mainframe, COBOL developers, at least this one, had to make sure the code was sound before submitting your code to the queue. Comparatively speaking, if I crash my system, 1 person is down for a little while, but if you take down an entire mainframe region, there's a little more impact. (I am not picking on COBOL developers here, it's just part of the story.)

Compare that to TDD, where my mindset is, "hey, if I refactor this chunk of code into a method, these two other block are the same, and could be made a delegate. Let's try that!" Or, things like "I don't like that switch statement, lets make it a dictionary". Compile, Run Tests…. oops, the entire test fixture fails, oh well, ctl-z.

This tantalizing story leads me up to these few points:

Profound statement #1: TDD is an incredible gift. Having a series of unit tests gives you the confidence and comfort to try really crazy things with your code. It also gives you the ability to enforce some of the higher level design patterns to make your code truly awesome; open closed principle, single responsibility, Liskov substitution principle, to name a few.

Profound statement #2: TDD has made me lazy. I let my tests find my bugs.

Profound statement #3: TDD has made me confident. I realize that this statement might conflict with statement #2, but mixing of these traits just makes me smile. If my QA tester finds a bug, I can write a test to re-produce the issue and can guarantee that bug will not surface again.

Profound statement #4: You need productivity tools like ReSharper and TestDriven .Net. Not to sound like a commercial for ReSharper, but man, that stuff is like crack! When you combine those tool suites, with your IDE, you can do really fun things when pairing like "mouse free Thursday's". Once you learn all the keyboard shortcuts within an IDE, you realize the mouse is a distraction. The speed, fluency and pace you can write, and refactor code triples when you are not fumbling around with that little pointy arrow. You find that your thoughts are focused on your end goal and not scrolling through your code looking for those pesky syntax problems like missing curly bracket or missing semi-colon. And yes, it is a bad habit to rely on the compiler to tell you were that missing semi-colon is!

So now here's my disclaimers.

  1. I have respect for COBOL programmers, my intent here was to not poke fun at them.
  2. I am not pushing ReSharper or TestDriven.Net, those are the tools we use. There are productivity tools out there. ( If Dustin Campbell reads this, I'll have already heard the groans when I mention ReSharper!)
  3. Mouse-Free Thursdays is an awesome experience. While pairing, each developer unplugs their mouse, only for Thursday and only while coding. After a few MFT's, you find you are a much more efficient coder.

Tuesday, April 22, 2008

F# Pattern Matching

After my last post on the sample F# test runner, I realized I missed a post on one of the critical constructs F# has to offer; pattern matching. Pattern matching does exactly what it sounds like, matches patterns.
let action x = 
     match x with
     | "Red" -> "Stop"
     | "Green" -> "Go"
     | _ -> "I don't know"
In this example, when I pass the colors Red or Green to the action function, it returns the matching value. If I were to pass blue to the function, I would get back "I don't know".
> action "Red";; val it : string = "Stop" > action "Blue";; val it : string = "I don't know"
Notice the "_" at the end, it is a wildcard and it makes this pattern match exhaustive. If I didn't include the _, F# would complain I had an incomplete match. You do have to be careful of where you put your wildcard character. The following function would create a scenario where the "Green" match statement would not be evaluated:
let action x = 
     match x with
     | "Red" -> "Stop"
     | _ -> "I don't know"
     | "Green"  -> "Go"
This control structure should seem very familiar to anyone coming from the C language family. Indeed, the action function could be written as an if..else statement or a switch statement in C#:
   public static string Action(string color)
        {
            if (color == "Red")
            {
                return "Stop";
            }
            else if( color == "Green")
            {
                return "Go";
            }
            else
            {
                return "I don't know";
            }
        }
You can include conditions within your matches, take the following function:
let isEven x =
     match x with
     | _ when x % 2 = 0 -> true
     | _ -> false
With conditions however, you need to have a catch all. If I were to change the above function to read like this:
let isEven x =
     match x with
     | _ when x % 2 = 0 -> true
     | _ when x % 3 = 0 -> false
the complier would complain of an incomplete pattern match. With pattern matching you can decompose structured values. This example breaks down the tuples for the match.
let isCubeEven x =
     match x with
     | _ when snd x % 2 = 0 -> (fst x,true)
     | _ -> (fst x,false)
This function returns the following in fsi:
> isCubeEven (3,9);; val it : int * bool = (3, false)
The example "isCubeEven" highlights two features of what makes F# exciting. First, notice that I didn't need to explicitly annotate any of my variables with types? The F# complier inferrs that x is a tuple because of the way I use it within my function. And second, the fst and snd functions that let me easily work with tuples to get the first and second values. Pattern matching becomes really powerful when you combine it with rec, the keyword for recursive functions. Take this function for adding up the numbers in a number:
let rec sumDigits x y =
    match x with
          | x when x = 0 ->  y
          | x -> sumDigits (x / 10) (x % 10) + y
This particular function I wrote to solve some of the Project Euler problems. With this function y accumulates the running summed value and x gets chopped up from right to left.
> sumDigits 123456789 0 val it : int = 45
When you combine the rec keyword and pattern matching, the possibilities are infinite. Take the fold_left function from the F# list namespace:
let rec fold_left f s l = 
     match l with 
     | [] -> s 
     | (h::t) -> fold_left f (f s h) t
The fold_left function takes a function f, a seed value s, and a list l. The match uses the list processing keys to get the first element h and remainder of the list t. Then calls itself with the same function, the result of the function applied to the seed value and the first element and the rest of the list. Pattern matching also works great on records, here's a great post on that by Mike Gold. Question and comments are welcome!

Friday, April 11, 2008

Sample F# Test Runner (and C# too...)

While I was fooling around with F# and testing my functions, I got really annoyed with switching between applications to run my tests, Visual Studio and NUnit Gui. The source of my fustration is during the day I get to use a fantastic tool TestDriven.Net to run my unit tests in C# and Visual Studio. With F#, however, TestDriven.Net does not recognize the different syntax and no tests run. So I decided to write my own test runner, by taking advantage of .Net's FileSystemWatcher class. (Note, I used the FileSystemWatcher.Changed event.1 ) The first iteration I wrote in C# so I could have an excuse to use xUnit. I probably over engineered the C# code, but old habits die hard. In the C# implementation, there are three files. The program class sets everything up, the HarnessRunner class sets up the filesystem watcher and listens for the file changed event, and finally the ProcessStarter to run the process. The application is configurable to use the app.config or to pass any necessary commands to the program. ( Hence a little of the bloat.)
using System;
using System.IO;

namespace HarnessRunner
{
    public class program
    {
        [STAThread]
        public static void Main(string[] args)
        {
            Settings settings = Settings.Default;

            if (ValidateInputValue(settings.TestRunnerCommand))
            {
                Console.WriteLine("Enter the fully qualified command to run:\r\n");
                settings.TestRunnerCommand = Console.ReadLine();
            }

            if (ValidateInputValue(settings.TestAssembly))
            {
                Console.WriteLine("Enter the file to test:\r\n");
                settings.TestAssembly = Console.ReadLine();
            }

            if (ValidateInputValue(settings.TestRunnerSwitches))
            {
                Console.WriteLine("Enter any swtiches to the test runner:\r\n");
                settings.TestRunnerSwitches = Console.ReadLine();
            }
                     
            Console.WriteLine("Setting up the watcher to run: \r\n{0} {1} {2}", Path.GetFileName(settings.TestRunnerCommand),
                              Path.GetFileName(settings.TestAssembly),settings.TestRunnerSwitches);
            try
            {
                HarnessRunner runner = new HarnessRunner(new FileSystemWatcher(), new ProcessStarter());
                runner.InitializeFileSystemWatcher(settings.TestAssembly);
            }
            catch (Exception e)
            {
                Console.WriteLine("There was an exception during the run: {0}{1}{2}", e.Message, Environment.NewLine,
                                  e.StackTrace);
            }
            Console.ReadLine();
        }

        private static bool ValidateInputValue(string command)
        {
            return string.Compare(command, string.Empty) == 0;
        }
    }
}
using System;
using System.Diagnostics;
using System.IO;

namespace HarnessRunner
{
    public interface IStartTestHarnesses
    {
        string Start();
    }

    public interface IFileSystemWatcher
    {
        bool EnableRaisingOfEvents { get; set; }
        string Path { get; set; }
        NotifyFilters NotifyFilter { get; set; }
        event EventHandler Changed;
    }

    public class ProcessStarter : IStartTestHarnesses
    {
        public string Start()
        {
            Settings settings = Settings.Default;
            Process process = new Process();
            process.StartInfo.FileName = settings.TestRunnerCommand;
            process.StartInfo.Arguments = settings.TestAssembly + " " + settings.TestRunnerSwitches;
            process.StartInfo.UseShellExecute = false;
            process.StartInfo.RedirectStandardOutput = true;
            process.Start();

            return process.StandardOutput.ReadToEnd();
        }
    }
}
using System;
using System.IO;

namespace HarnessRunner
{
    public class HarnessRunner
    {
        private FileSystemWatcher fileSystemWatcher;
        private IStartTestHarnesses startTestHarnesses;

        public HarnessRunner(FileSystemWatcher fileSystemWatcher, IStartTestHarnesses startTestHarnesses)
        {
            this.fileSystemWatcher = fileSystemWatcher;
            this.startTestHarnesses = startTestHarnesses;
            fileSystemWatcher.Changed += fileSystemWatcher_Changed;
        }

        private void fileSystemWatcher_Changed(object sender, FileSystemEventArgs e)
        {
            Console.WriteLine(startTestHarnesses.Start());
        }

        public void InitializeFileSystemWatcher(string filetowatch)
        {
            fileSystemWatcher.Path = Path.GetDirectoryName(filetowatch);
            fileSystemWatcher.Filter = Path.GetFileName(filetowatch);
            fileSystemWatcher.NotifyFilter = NotifyFilters.LastWrite;
            fileSystemWatcher.EnableRaisingEvents = true;
        }
    }
}

So, once I had that working, I decided to write the F# equivalent. There are two functions, one that starts the process and one to setup the filesystemwatcher. Other than that, there are just some config options.
#light

open System
open System.IO
open System.Diagnostics
open System.Configuration

let mutable command = ConfigurationManager.AppSettings.Item("TestRunnerCommand")
let mutable testAssembly = ConfigurationManager.AppSettings.Item("TestAssembly")
let mutable commandSwitches = ConfigurationManager.AppSettings.Item("TestRunnerSwitches")

let startProcess f =
     let p = new Process()
     p.StartInfo.FileName <- command
     p.StartInfo.Arguments <- f ^" "^commandSwitches
     p.StartInfo.UseShellExecute <- false
     p.StartInfo.RedirectStandardOutput <- true
     let started = p.Start()
     printfn "%O" (p.StandardOutput.ReadToEnd())

let SetupFileSystemWatcher f =
     let fileSystemWatcher = new FileSystemWatcher()
     fileSystemWatcher.Path <- System.Environment.CurrentDirectory
     fileSystemWatcher.Filter <- f
     fileSystemWatcher.NotifyFilter <- NotifyFilters.LastWrite
     fileSystemWatcher.EnableRaisingEvents <- true
     fileSystemWatcher.Changed.Add(fun _ -> startProcess f)
   
if command = ""  command = null then
     printfn "Enter the fully qualified command to run:\r\n"
     command <- Console.ReadLine()       
if testAssembly = ""  testAssembly = null then      
     printfn "Enter the file to test:\r\n"
     testAssembly <- Console.ReadLine()
if commandSwitches = ""  commandSwitches = null then
      printfn "Enter any swtiches to the test runner:\r\n"
      commandSwitches <- Console.ReadLine()

printfn "Setting up watcher for %A" testAssembly  
SetupFileSystemWatcher testAssembly 
read_line() 
So, now that the code is posted, I'm left with some sort of follow up point to wrap this post up. The only problem is, I can't seem to come up with any points! I put together this article to show a program that performs the same function, implemented in two separate languages. Comments, feedback and discussions are welcome! 1 For some reason, the FileSystemWatcher.Changed event fires three times when my assembly is compiled.

Wednesday, March 19, 2008

Visual Studio 2008 launch in Detriot

Wow - I just came back from Microsoft's Hero's Happen Here event in Detroit to launch Visual Studio 2008, Windows Server 2008 and SQL Server 2008. It was a well organized event, but more important to me was to catch up with everyone I met at this years CodeMash event. I always leave these events with a tremendous sense of community. Special thanks to Keith Elder, who hosted the geek dinner afterwards. (An extra special thanks to Randy Pagels!) At this event I was able to meet fellow F# blogger Dustin Campbell and share a few thoughts on F#. I wish I had more time to talk shop......... I was also able to meet Jeff McWherter, Joe Wirtley and spend six quality hours in the car with Corey Haines and Michael Letterle. Well, Corey was only awake for three.... Another reason for the feeling of community was the presence and dedication of Microsoft's regional representatives, Josh Holmes, Brian Prince, Darryl Hogan and Jeff Blankenburg. Hope to see you all again soon!

Saturday, March 8, 2008

Records and Discriminated Unions

Like most other programming languages, it is possible with F# to create your own types when needed. Because F# is a blend of both functional languages and imperative languages, you get support for types from a functional perspecive as well as types when you have to deal with OO programming. Records Records are concrete type definitions, if you have an OO background, records will look very similar to classes. To create a record, you need to tell F# the type name, the labels and the label type. Here’s an example, using FSI
> type FamilyMember = {Name: string; relation: string};;
type FamilyMember = {Name: string; relation: string;}
There are two different ways to create record. The first way:
> {Name = "Nate";relation = "Father"};;
val it : FamilyMember = {Name = "Nate"; relation = "Father";}
Or a more explicit syntax:
> {new FamilyMember with Name = "Kelly" and relation = "Mother"};;
val it : FamilyMember = {Name = "Kelly"; relation = "Mother";}
F# makes it easy for you to access the record labels:
> let f = {new FamilyMember with Name = "Nate" and relation = "father"};;
val f : FamilyMember
> f.Name;;
val it : string = "Nate"
Records can be cloned, and like everything else with F#, it’s amazingly simple!
> let d1 = {new FamilyMember with Name = "reilly" and relation = "daughter"};;
val d1 : FamilyMember
> let d2 = {d1 with Name = "Cora"};;
val d2 : FamilyMember
> d2;;
val it : FamilyMember = {Name = "Cora";
relation = "daughter";}
Records can be results of functions as well. Take the following type, which has a count of files and a count of directories:
type FilesAndDirectorys = {Files: int; Directories: int;}
We can use it for a function like so:
let GetFilesAndDirectories loc =
let dirs = Directory.GetDirectories(loc)
let files = Directory.GetFiles(loc)
let results = {new FilesAndDirectorys with Files = files.Length and Directories = dirs.Length}
results
Next call the function with the path you want to search
let counts = GetFilesAndDirectories @"C:\" The identifier counts now contains the following data:

val it : FilesAndDirectorys = {Files = 9; Directories = 18;}

There is another type, discriminated union types, but I'll save those for another blog entry.

Friday, February 15, 2008

Basic Type conversions with F#

As I work my way through the ProjectEuler problems they forced me to look into working with the different types in F#. F# is a very strongly typed language, but it has the same basic types as the types in the other .Net languages. Here is a list of the basic types and how to tell the compiler you want to use them:
let int = 42
let string = "This is a string"
let char = 'c'
let bool = true
let bytearray = "This is a byte string"B
let hexint = 0x34
let octalint = 0o42
let binaryinteger = 0b101010
let signedbyte = 68y
let unsignedbyte = 102uy
let smallint = 16s
let smalluint = 16us
let integer = 345l
let usignedint = 345ul
let nativeint = 765n
let unsignednativeint = 765un
let long = 12345678912345L
let unsignedlong = 12345678912345UL
let float32 = 42.8F
let float = 42.8
(Definitions for the types are listed here.) F# also has BigInt and BigNum types, they stand for arbitrary large integer and arbitrary large number respectively. (I don't know how big they are yet.)
let bigInt = 9876543219876I
let bigNum = 123456789987654N
The F# compiler will determine the types you are working with, a feature called Type Inference. To see what types are inferred, compile your fs files using the –i switch to create an FSI (F# Interface file) or use the mouse in Visual Studio. Most of the F# programming you will do, inference will work. Now, I know some of you might be thinking; “Yeehaw! I don’t have to worry about declaring types! I’m free!!” Well…some of you might have, I did. If you want force a type and not let inference handle it for you, you have to use the conventions above like so:
> 3423456573476N;;
val it : bignum = 3423456573476N
> "This will be a string of bytes"B;;
val it : byte []
= [84uy; 104uy; 105uy; 115uy; 32uy; 119uy; 105uy; 108uy; 108uy; 32uy; 98uy;
101uy; 32uy; 97uy; 32uy; 115uy; 116uy; 114uy; 105uy; 110uy; 103uy; 32uy;
111uy; 102uy; 32uy; 98uy;121uy; 116uy; 101uy; 115uy]
> 0x06D;;
val it : int = 109
But what happens if you have to convert between types? Well, F# has conversion methods like so:
> let x = 42;;
val x : int
> let bigx = Int64.of_int x;;
val bigx : int64
> bigx;;
val it : int64 = 42L
The first statement let x = 42 and the resulting line val x : int is an example of type inference. The F# compiler infers that 42 is of type Int32. OK, not really too much here to write home about. The second statement Int64.of_int actually converts x to a type of Int64, as demonstrated by the output “42L”. Again, not too much here to write home about. There are methods to convert the types between each other. I just didn't write them all. Type inference is great, but you have to be careful when you try things like this:
> let reallybignum = 123456789456123789;;
let reallybignum = 123456789456123789;;
-------------------^^^^^^^^^^^^^^^^^^^
stdin(4,19): error: error: This number is outside the allowable range for 32-bit signed integers
Oops, I tried to stuff a number larger than what a 32 bit number can hold. To fix this, we need to specify a 64 bit integer:
> let reallybignum = 123456789456123789L;;
val reallybignum : int64
OK, as exciting as writing about types and type inference are there is another part to this post. I was poking around through the source code and came across the conversion code F# uses. Here’s the method for converting an int to other data types:
let inline int32 (x: ^a) = (^a : (static member ToInt32: ^a -> int32)(x))
when ^a : string = (System.Int32.Parse(castToStringx,System.Globalization.CultureInfo.InvariantCulture))
when ^a : float = (# "conv.i4" x : int32 #)
when ^a : float32 = (# "conv.i4" x : int32 #)
when ^a : int64 = (# "conv.i4" x : int32 #)
when ^a : int32 = (# "conv.i4" x : int32 #)
when ^a : int16 = (# "conv.i4" x : int32 #)
when ^a : nativeint = (# "conv.i4" x : int32 #)
when ^a : sbyte = (# "conv.i4" x : int32 #)
when ^a : uint64 = (# "conv.i4" x : int32 #)
when ^a : uint32 = (# "conv.i4" x : int32 #)
when ^a : uint16 = (# "conv.i4" x : int32 #)
when ^a : unativeint = (# "conv.i4" x : int32 #)
when ^a : byte = (# "conv.i4" x : int32 #)
Wow, there’s a lot going on here, but overall it should look familiar; it's a function. The inline keyword is a pseudo-function marker for code expansion. Which means the compiler will copy the function inline to the call site. The ^a parameter designates a static head-type, which means the type must be known at compile time. The : type parameter in this case is a type constraint on the value. The (# “conv.i4” : int32 #) is a special syntax for a feature of the F# language, inline il. I know I went through that fast, but at this point a lot of this stuff is specific to the compiler. More detail than I can explain.

You could read this line: when ^a : int64 = (# "conv.i4" x : int32 #) as "when ^a is a type of int64 use the il instruction conv.i4 passing in the value (x) to convert and tell the compiler the type is an int32".

A little about the IL part of the line; (# “conv.i4” x : int32 #). The (# #) block tells the compiler, here comes an IL instruction. The conv.i4 is the il opt code for convert to an int32, x is value to convert and the : int32 completes the IL instruction to enforce the int32 type.

Even though this example if fairly implicit, I ran and got my copy of Expert .Net 2.0 IL Assembler book by Serge Linden and found conv is indeed the IL code for convert operations and i4 is the int32 type. Conv takes the value from the stack, converts it and puts it back. Type conversions are tricky, if you reduce the size of a value, i.e. – int64 -> int32, the most significant bytes are throws away. Likewise if you increase the size of the value int32 -> int64 the value is zero extended.

let reallybignum = 123456789456123789L;;
val reallybignum : int64
> let truncated = Int32.of_int64 reallybignum;;
val truncated : int32
> truncated;;
val it : int32 = -1062963315
If we look at how F# handles these conversions, we find the code:
when ^a : int64 = (# "conv.ovf.i4" x : int32 #)
The optcode conv.ovf.i4 is the IL overflow conversion operator. If the conversion truncates, an Overflow exception is thrown. That’s all for now, comments, questions and corrections are welcome!

Sunday, February 10, 2008

Project Euler

Wow - If you are looking for a great web site for exercising you skills in F#, or your programming language of choice, then sign up for ProjectEuler. I've made it through a few of the problems, and they are mind stretchers. I’ve had to try to remember stuff I haven't had to think about for over 15 years! Another advantage of this site is once you solve the problem, you can see how others have solved them in a variety of languages.

Sunday, January 27, 2008

Walking the F# List namespace - Post #3

This will probably be my last series on examining the source behind the List namespace. Only because I was running out of interesting functions that have interesting implementations, or functions that I feel I could adequately explain. And frankly, writing that List.filter actually imlements List.filter from another namespace is not too interesting. So, I took a look inside list.fs to find some interesting implementations and found a few more functions to walk through. List.assoc: List.assoc is roughly equivalent to a hashtable or dictionary lookup in c#, except the list is a list of tuples. (Also, I’m not sure if there are any index optimizations either.) Throws a not_found() exception if the key is not found. The signature for List.assoc is ‘a -> (‘a * ‘b) list -> ‘b
‘a – the key value to find
(‘a * ‘b) list – the source tuple list
‘b – the value for the key.
Here’s an example, using FSI:
> let list = [for x in 1 to 50000 -> (x,x*x)];;
val list : (int * int) list
>let findSquare s = List.assoc s list;;
val findSquare : int -> int
> findSquare 14513;;
val it : int = 210627169
If we look at the source code, List.assoc is implemented as:
let rec assoc x l =
match l with
|[] -> not_found()
|((h,r)::t) -> if x = h then r else assoc x t
The interesting code block with this function is the ((h,r)::t) syntax. The syntax of (h,r) is breaking up the tuple in the first element on the list, with h getting the key and r getting the value. If the key matches the passed in value, then return r. Also, if the list is empty ([]), then raise the not_found() exception. (I didn’t go into any detail about the rec or match, I describe them in further detail in my previous posts.) The documentation for List.assoc suggests we use List.try_assoc. So, lets try. List.try_assoc: essentially the same as List.assoc, with two main differences. First, try_assoc, will not throw a not_found() exception if the key is not found. Second, try_assoc returns an option type. When using F# code from other .Net languages, the empty option type (None) is equalivant to the null value. To create a value of the option type, you need to use Some or None. The signature for List.try_assoc is: ‘a -> (‘a * ‘b) list -> ‘b option
‘a – the first tuple element to find
(‘a * ‘b) list – the soure list
‘b option – the returned value
Here’s an example, from FSI.
> let list = [for x in 1 to 50000 -> (x,x*x)];;
val list : (int * int) list
> findSquare 50001;;
val it : int option = None
>findSquare 23;;
val it : int option = Some 529
If we look at the source code, List.try_assoc is implemented as
let rec try_assoc x l =
match l with
|[] -> None
|((h,r)::t) -> if x = h then Some(r) else try_assoc x t
Wow, this looks surprisingly similar to List.assoc, with the exception of the return types of None and Some(r). List.assq: List.assq is almost like List.assoc, except is used the PhysicalEquality operator. PhysicalEquality is defined in as “Reference/physical equality. True if boxed versions of the inputs are reference-equal, OR if both are value types and the implementation of Object.Equals for the type of the first argument returns true on the boxed versions of the inputs.” as defined in: http://research.microsoft.com/fsharp/manual/FSharp.Core/Microsoft.FSharp.Core.LanguagePrimitives.html So, generally speaking, List.assq does reference equality on values on the stack, whereas value equality compares values on the heap. I posted a question on an implementation of PhysicalEquality here (Kudos to zakaluka!) Anyway here’s how List.assq is implemented:
let rec assq x l =
match l with
|[] -> not_found()
|((h,r)::t) -> if PhysicalEquality x h then r else assq x t
List.try_assq is exactly the same as List.try_assoc, except the return type is an option type. Here’s the implementation:
let rec try_assq x l =
match l with
|[] -> None
|((h,r)::t) -> if PhysicalEquality x h then Some(r) else try_assq x t
List.for_all: Returns true if all the elements in the list satisfy the given predicate, false if one fails. The list elements are anded together, visualized as p iO && p i1 && .. p iN. The signature for list.for_all is (‘a -> bool) -> ‘a list -> bool
(‘a -> bool) – A function that evaluates the list element and returns a bool
‘a list -> the list to process
Bool -> return value
Here’s an example:
[<Test>]
member t.For_allExample () =
let list1 = [0 .. +2 .. 20]
let list2 = [1 .. 10]
let evens = List.for_all (fun x -> x % 2 = 0) list1
let notevens = List.for_all (fun x -> x % 2 = 0) list2
Assert.IsTrue(evens)
Assert.IsFalse(notevens)
List.for_all implements
let rec for_all f l1 = Microsoft.FSharp.Primitives.Basics.List.for_all f l1
Hmm, not so much fun to describe.....so on we go. List.for_all2: Returns true if all the elements in two lists satisfy the given predicate, false if one fails. The lists must have the same length. The signature for list.for_all2 signature is (‘a -> ‘b -> bool) -> ‘a list -> ‘b list -> bool.
(‘a -> ‘b -> bool) – A function that takes an element from the first list and the second list and returns a bool
‘a list – the first list
‘b list – the second list
Bool -> the return value
Here’s an example:
[<Test>]
member t.For_all2Example () =
let list1 = [0 .. +2 .. 20]
let list2 = [20 .. +2 .. 40]
let list3 = [1 .. 10]
let evens = List.for_all2 (fun x y -> x % 2 = 0 && y % 2 = 0 ) list1 list2
let notevens = List.for_all2 (fun x y -> x % 2 = 0 && y % 2 = 0) list2 list3
Assert.IsTrue(evens)
Assert.IsFalse(notevens)
List.for_all2 implements:
let rec for_all2 f l1 l2 =
match l1,l2 with
|[],[] -> true
|(h1::t1),(h2::t2) -> f h1 h2 && for_all2 f t1 t2
|_ -> invalid_arg "for_all2"
This recursive function is interesting, in particular the line (h1::t1),(h2::t2) -> f h1 h2 && for_all2 f t1 t2. The function aggregates the results of the function and the list elements!

Friday, January 18, 2008

Dustin Campbell on F#

I caught Dustin Campbell's presentation @ Code Mash. It was a great experience for me to just watch someone talk and type F# code for 40 minutes. Dustin has started blogging about F# also. Here's his podcast with Scott Hanselman.

Thursday, January 17, 2008

A few F# basics

I was driving to the Code Mash conference with a colleague last week and I started talking about F# and how I was really getting into it. He asked generally, "What's the main difference between F# and C#?". After drawing a complete blank and a long pause, I stammered out something like, there's really no one difference between the two languages, and began to ramble some of the differences I could recall. A few days later I went back and nosed through my copy of Robert Pickering's book; I refreshed what some of the main differences are. So I thought I'd jot some down. Disclaimer: I am just beginning to learn this language, everything here is my interpretation and I am sure there are more differences than the few I list. Identifiers and expressions - Identifier is the keyword to define a value. Expressions are any chunk of code that returns something.
let myname = "Nate"
In F#, as with other functional languages, all values are immutable. Once a value is assigned to an identifier the value never changes. Of course, like all languages, there are ways to let identifiers be mutable using the keyword mutable.

let mutable myName = "Nate"

myName <- "Etan"

Functions are identifiers- Functions in F# are first class entities and are treated just like identifiers.
let squares x = x * x
let cubes x = squares x * x
In this example, squares is the name of the function and x is the parameter. The function cubes takes it's parameter passes it to the square function. The result of the squares function gets included in the rest of the expression for cubes. Functions can also be curried. Currying is the process of passing a function with some arguments that returns you a function with a single argument. Consider the following snippet:
let p = 20
let add x y = x + y
let add13 = add 13
let answer = add13 p

answer = 33
Huh?? Let's take a walk through that. The add function has the signature of int -> int -> int, which reads; this function takes two ints and returns an int. The add13 function has the signature (int -> int) which reads; this function takes a function that returns an int and returns an int. The expression answer calls the add13 function, which calls the add function giving 1 parameter which gets assigned to x then p gets assigned to y on the add function. Type inference - F# is very strongly typed, but you don't have to explicitly declare the variable types. The F# compiler handles all that for you. Using FSI, you can see what the complier infers
> let s = "S"
val s : string
> let double = 2.3
val double : float
> let x = 0
val x : int
> let c = 'c'
val c : char
> let whatisthis q = q
val what : 'a -> 'a
The 'a means the complier could not infer what the type is so it uses a generic type. (Not to be confused with generics in C#.) Pattern matching and recursion - These two traits deserve their own respective posts. Pattern matching is conducive to if..elseif..else and switch statements in procedural languages and recursion means a function calls itself. Anonymous functions - anonymous functions, also called lambdas, that don't get an identifier. These functions are used as arguments to other functions. The keyword fun identifies these.
let divide q = (fun x y -> x / y) q 2
That's all for now, comments and feedback are welcome!

Walking the F# List namespace - Post #1

This will be the first part of a many part posting as I learn F#. Still being a research language, it's immense. So I thought, why not just pick a namespace and write a small bit of code to learn all the new functions in the FSharp.Collections.List namespace. F# comes complete with the source code, which is written in F# and one of the best ways to learn a new language and to find the "best" or "right" ways of writing new code is to spend as much time reading code as you do writing code. (Scott Hanselman has a great blog entry on reading code.) I took a TDD approach to help make my way through, so each code snippet is actually a small NUnit test. To get a project configured for vs2008, take a look here. For some of the simpler syntax, I used F# Interactive (FSI). Lists, like everything in F#, are immutable, which means once one is created, you cannot change them. Also, lists can only contain members of the same type, you do have the ability to create a list of an obj type. Lists are a built in data structure that is basically a concatenation of the head and tail. The head being the first element and the tail the remainder of the list, as you'll see later on as we get into the source code. The syntax to create a list is use the :: followed by an empty list []. The :: syntax stands for cons.)
let list = "blue" :: "red" :: "green"
Like most programmers, I'm a lazy typer, so this shorthand also works.
let list = ["blue";"red";"green"]
To concatenate two lists, use the @ symbol
let list = ["blue";"red";]@["yellow";"green"]

To bring out some of the power of F# you can also create lists using comprehensions:

let numbers = [1 .. 10] = [1; 2; 3; 4; 5; 6; 7; 8; 9; 10]
let chars = ['a' .. 'f'] = ['a'; 'b'; 'c'; 'd'; 'e'; 'f']
let cubes = [ for x in 1 .. 5 -> x * x * x] = [1; 8; 27; 64; 125]
So, on to the first function! List.append: This function returns a new list from two lists that are passed to the function in the order they are passed. The method signature of append is

'a list -> 'a list -> 'a list

A little on the signature, List.append first and second arguments are of type 'a list and returns 'a list (remember 'a is how the compiler infers a generic type.)

let list1 = [2 .. +2 .. 10]
let list2 = [1 .. +2 ..9]
let appended= List.append list1 list2
combined = [2;4;6;8;10;1;3;5;7;9;] Lets take a look at how this function is implemented:
let append l1 l2 = l1 @ l2
List.exists: Tests if any element in the list statisy the given predicate. (A predicate is a statement that returns true or false.) The signature of exists is ('a -> bool) -> 'a list -> bool.
('a -> bool) is the function that applies the predicate to item 'a 'a -> list is your list bool is the return value
Here's an example:
[<Test>]
member t.Listexists() =
let list1 = ["The";"quick";"brown";"fox";"jumped";"over";"the";"lazy";"dog"]
let answer = List.exists (fun x -> x = "fox") list1
let wrong = List.exists (fun x -> x = "Fox") list1
Assert.IsTrue(answer)
Assert.IsFalse(wrong)
Lists.exists under the covers is:
let rec exists f l1 = Microsoft.FSharp.Primitives.Basics.List.exists f l1

The signature of Microsoft.FSharp.Primitives.Basics.List.exists is the same of the List.exists function

Here we the first use if the rec keyword. Rec stands for recursion, which means this function calls itself. F# recursion is a core concept, it works with lists by getting the head which is the first element and the tail which is the rest of the list, so until tail is empty [], the function will be called with each element in the list.

Lists.exists2: Same as List.exists, but works with two lists. If the lists don't match in length, it throws an Invalid_ArgumentException. Exists2 signature is: ('a -> 'b -> bool) -> 'a list -> 'b list -> bool.
('a -> 'b -> bool) is the function that applies the predicate to item 'a and item 'b
'a -> list is your first list
'b -> list is your second list
bool is the return value
Here's an example:
[<Test>]
member t.Listexists2() =
let list1 = ["The";"quick";"brown";"fox";"jumped";"over";"the";"lazy";"dog"]
let list2 = ["Some";"other";"thing";" ";"jumped";"around";"another";"restless";"mammal"]
let list3 = ["Some";"other";"thing";"Jumped";"winking";"around";"another";"tired";"mammal"]
let answer = List.exists2 (fun x y -> x = y) list1 list2
let wrong = List.exists2 (fun x y -> x = y) list1 list3
Assert.IsTrue(answer)
Assert.IsFalse(wrong)

[<Test;expectedexception(type Invalid_argumentException)>]
member t.Listexists2exception() =
let list1 = ["The";"quick";"brown";"fox";"jumped";"over";"the";"lazy";"dog"]
let list2 = ["Some";"other";"thing";"jumped";"around";"another";"restless";"mammal"]
let answer = List.exists2 (fun x y -> x = y) list1 list2
Assert.IsTrue(answer)
List.exists2 under the covers:
let rec exists2 f l1 l2 =
match l1,l2 with
| [],[] -> false
| (h1::t1),(h2::t2) -> f h1 h2 exists2 f t1 t2
| _ -> invalid_arg "exists2"
Ahh - the rec keyword again, but this time paired with match. Match is F# pattern matching. The match statement is working with each list, the first condition [],[] says if both lists are empty then return false. The (h1::t1),(h2::t2) -> f ht h2 exists2 f t1 t2 gets the head and tail for each list and applies the function to h1 and h2 then passes the function and the rest of each list back to exists. The _ character basically is a wildcard to catch everything else. List.filter: Returns a new list that only contains the elements that the given predicate returns true. The signature ('a -> bool) -> 'a list -> 'a list.
('a -> bool) = the function that each element is applied to the
predicate
'a list = the list supplied to List.filter
'a list = the new list
Here's an example:
[<Test>]
member t.Listfilter() =
let list1 = [1 .. 10]
let list2 = List.filter (fun x -> x % 2 = 0) list1
Assert.AreEqual([2 .. +2 .. 10],list2)
So what's happening internally?
let filter f x = Microsoft.FSharp.Primitives.Basics.List.filter f x
The signature for Microsoft.FSharp.Primitives.Basics.Lists.filter function is the same for List.filter. List.find: Returns the element in the list where the given predicate returns true. Throws a Not_Found exception if no element is found. The signature is: ('a -> bool) -> 'a list -> 'a.
('a -> bool) the function to evaluate 'a
'a list = the list to work with
'a = the return value

Here's an example:

[<Test>]
member t.ListFindTest() =
let list = [1 .. 9]
let a = List.find (fun x -> x = 2) list
Assert.AreEqual(a,2)
Internally, what is implemented is once again our rec and match expressions!
let rec find f l =
match l with [] -> not_found()
¦ h::t -> if f h then h else find f t
The find function takes a function and the list, checks for an empty list if it's empty then throw a not_found() exception, otherwise get the head and tail. Apply the value in h to the function, if it's true, it returns h, otherwise pass the function and the tail back to find. You again see here the power of functional languages core functions of rec, match and list processing. Being able to get the first element in a list with simply stating h::t; what a change from having to enumerate lists with for or foreach loops! Lind.find_all: Returns a new list of all the elements where the given predicate returns true. The signature is ('a -> bool) -> 'a list -> 'a list.
('a -> bool) the function to evaluate 'a
'a list = the list to work with
'a list = the new list with all the elements that met the predicate
Here's an example:
[<Test>]
member t.ListFind_All() =
let list = [1;2;3;5;7;11;13;16;17;19;23]
let evens = List.find_all (fun x -> x % 2 = 0) list
Assert.AreEqual([2;16;],evens)
Behind the scenes List.find_all implements:
let find_all f x = Microsoft.FSharp.Primitives.Basics.List.filter f x
Which is the same method that List.filter uses! List.partition: This is an interesting function, it splits a list based on the predicate, the first is contains all elements that return true, the second list is all the elements that return false. The signature is: ('a -> bool) -> 'a list -> 'a list * 'a list.
('a -> bool) the function to evaluate each element
'a list - the source list
'a list * 'a list - the returned list that contains a tuple of the
elements.
The 'a list * 'a list signature identifies a tuple, not multiplication. The returned list contains two lists. Here's an example:
let list = [1;2;3;5;7;11;13;16;17;19;23]
let newlist = List.partition (fun x -> x % 2) list
newlist = ([2; 16], [1; 3; 5; 7; 11; 13; 17; 19; 23])
With F# you can add on the identifiers like such:
let list1,list2 = List.partition (fun x -> x % 2 = 0) list
list1 = [2;,16;]
list2 = [1; 3; 5; 7; 11; 13; 17; 19; 23]
Wow! The partition function returns a list of tuples, which the let statement is asking for each identifier to get one. By separating the identifiers by commas, it tells the compiler to assign one of the tuple values to each of the identifiers. If I enter the following statement into fsi
let list1, list2,list3 = List.partition (fun x -> x % 2 = 0) list
-------------------------^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

stdin(8,25): error: FS0001: Type mismatch. Expecting a
'a * 'b * 'c
but given a
'd list * 'd list.
The tuples have different lengths
Under the covers List.partiation uses:
let partition p x = Microsoft.FSharp.Primitives.Basics.List.partition p x
Enough for now, comments and feedback are welcome!

Tuesday, January 15, 2008

Walking the F# List namespace - Post #2

Continuing on with my walkthrough of the Microsoft.FSharp.Collections.List namespace, I thought I’d give the folding functions a shot. It took me some to time to understand what the functions were accomplishing, but after a few tests, they became clear. List.fold_left: This applies a function to each element in the list and starts an aggregate argument to apply through the rest of the elements. Additionally, the function is given a seed value. The seed value and the first element are passed to the function, the result and the second element are passed to the function, that result and the third element….you get the point. Fold_left can be described as
f(..f(f((f s i0 ) i1)i2)..) in
The signature for List.fold_left is (‘b -> ‘a -> ‘b) -> ‘a list -> ‘b
(‘b -> ‘a -> ‘b) - the function that takes the seed value (‘b) and the
first element (‘a). The function returns ‘b.
‘a list - the source list
‘b - the result

Here’s an example:

[<Test>]
member t.Listfold_left() =
let list = [1 .. 4]
let answer = List.fold_left (fun x y -> x*y) 2 list
Assert.AreEqual(48,answer)
Behind the scenes, List.fold_left is implemented as:
let rec fold_left f s l =
match l with
¦ [] -> s
¦ (h::t) -> fold_left f (f s h) t
Sweet, fold_left is simply a recursive match! The parameters to fold_left are the function (f), the seed (s) and the list (l). If the list is empty, simply return the seed value, because the seed value applied to nothing is the seed value. The (h::t) statement is a thing of beauty, it gets the first element in the list (h) and the rest of the list (t), then calls itself with the function (f), the result of function applied to the seed value and the first element, (f s h) and the tail. List.fold1_left: This applies a function to each element in the list and starts an aggregate argument to apply through the rest of the elements. It takes the first and second elements applies the function, the result and the third function are then given the function, until the end of the list returning the result.
f(..f(f((f i0 i1) i2)i3)..) in 
The signature for the function is (‘a -> ‘a -> ‘a) -> ‘a list -> ‘a
(‘a -> ‘a -> ‘a) - the function to apply the first element to the second
element and return the value
‘a list - the source list
‘a - the return value
Here’s an example:
let list = [1 .. 9]
let total = List.fold1_left (fun x y -> x * y) list
Total = 362880 You can also do a short hand operator with fold1_left, like so:
let total = List.fold1_left (+) list
Total = 45 List.fold1_left behind the scenes is implemented like so:
let fold1_left f l =
match l with
¦ [] -> invalid_arg "List.fold1_left"
¦ (h::t) -> fold_left f h t
Ahhh simplicity! Note the fold1_left function does not have the rec keyword. Given the function (f) and the list (l), the match statement checks for an empty list, if so, throw an invalid argument exception. Next split the list (h::t) and then call fold_left with the function (f), first element (h) and the rest of the list (t).

List.fold_left2: This applies a function to each element in two lists and starts an aggregate calculation based on a seed value and each corresponding list element. Then takes the result and applies it to the second element, and so on. Returning the result. The lists must be the same size. List.fold_left2 can be displayed as

f(..f(f((f s i0 j0 ) i1 j1)i2 j2)..) in jn
The signature for fold_left2 is (‘c -> ‘a -> ‘b –> ‘c) -> ‘c -> ‘a list -> ‘b list -> ‘c
(‘c -> ‘a -> ‘b –> ‘c) - This is a function that takes arguments of ‘c; the seed value, ‘a; an element from list1 and ‘b; an element from list2 and returns ‘c.
‘c – The seed value
‘a list – The first List
‘b list – The second list
‘c – The return value
Here’s an example:
let list1 = [1 .. +2 .. 9]
let list2 = [2 .. + 2 .. 10]
let answer = List.fold_left2 (fun c a b -> c + a + b) 10 list1 list2
Answer = 65 Here is how is this function implemented.
let rec fold_left2 f acc l1 l2 =
     match l1,l2 with
     | [],[] -> acc
     | (h1::t1),(h2::t2) -> fold_left2 f (f acc h1 h2) t1 t2
     | _ -> invalid_arg "List.fold_left2"
This looks very much like the fold_left function above. Fold_left2 takes the parameters of a function (f), the seed value (acc) and two lists (l1) and (l2). The first condition of the match statement checks if both the lists are empty, if so, it returns the seed value (acc). Next it splits the lists by using the (h::t) function and calls itself, by passing the function (f), the result of the function, the seed value and the heads of both lists, (f acc h1 h2) and both list tails.

Sample setup for Visual Studio 2008 for F# Unit Testing with NUnit

Here is an example of how I configured a vs2008 solution for building a small F# application using Test Driven Development (TDD) techniques and NUnit. I thought I’d share. Here’s the directory structure layout: C:\Projects\F#Projects\myApp · contains the sln file C:\Projects\F#Projects\myApp\myApp · contains the “production” fs files and fsharp project files C:\Projects\F#Projects\myApp\myApp_Tests · contains the test fs files and fsharp project files C:\Projects\F#Projects\myApp\Output · has a copy of nunit.framework.dll I started with a new F# solution and added two projects, myApp and myApp_Tests, both projects have their output paths set to the output directory. The myApp project I configured to be an exe and the myApp_Tests project I configured it to be a dll. (What the myApp project is compiled to really doesn’t matter, it all depends on your final use.) There’s a few additional configuration tasks I had to setup before I could start coding. In the myApp project I qualified it with module myApp so my code and tests could be in separate files. In the myApp_Tests project, I updated the DLL references section with these two entries: -r "C:\Projects\F#Projects\myApp\Output\Nunit.framework.dll" -r "C:\Projects\F#Projects\myApp\Output\myapp.exe" If you don’t want to update the dll references properties, you can add the references in your fs file as listed below. #r @"..\Output\nunit.framework.dll" #r @"..\Output\myapp.exe" I also had to set a project dependancy order to build myApp first then myApp_Tests second, via the solution properties menu. Whew, at last I can new write some code! (The formatting is a little off due to the encoding.) Here’s the myApp_Tests.fs file:
#light open NUnit.Framework [<TestFixture>] type myAppTests = class new() = {} [<Test>] member t.ShouldReturn2() = Assert.AreEqual(2,myApp.AddTwoNumbers(1,1)) [<test>] member t.ShouldReturn45() = Assert.AreEqual(45,myApp.AddTwoNumbers(13,32)) end
Here’s the myApp.fs file:
#light module myApp let AddTwoNumbers a b = a + b
Once you build your solution you can open Nunit Gui, find your test assembly and run your tests untill your in the green! (Make sure you enable NUNit’s shadow copy, so you can keep you project and Nunit open at the same time.) When you add a test, go back to NUnit and re-run, your new test will automatically show up. Feeback and comments are welcome! Enjoy!