Rick Minerich's Development Wonderland : functional

F# Discoveries This Week 05/02/2010

RickM — Sun, 02 May 2010 21:43:06 GMT

Back this week with another huge batch of F# links. While there’s way too much great stuff to mention, my favorite this week is by a mysterious blogger known only as James. His heat transfer model is short, sweet and very well explained.

If you’re around Boston tomorrow (Monday) be sure to check our F# panel for .NET Rocks! With over 100 people already signed up, it’s sure to be a great time.

The .NET Rocks! Visual Studio Road Trip – F# Edition in Boston (5/3/2010)

Carl and Richard are loading up the DotNetMobile (a 30 foot RV) and driving to your town again to show off the latest and greatest in Visual Studio 2010 and .NET 4.0! This stop will include an intro to F# and a special topic panel discussion on F# featuring New England F# User leaders.

Rob Knies’ F#: Putting the 'Fun' into 'Functional' (On Dr. Dobbs)

"In the F# team," says Syme, a principal researcher at Microsoft Research Cambridge, "We say, 'F is for Fun.' F# enables users to write simple code to solve complex problems. Programming with F# really does make many programming tasks simpler, and our users have consistently reported that they've found using the language enjoyable."

James’s Modelling heat transfer in F# using 100 lines of code

In this post I’m going to show how we can model the heat equation succinctly in F#. I’m going to consider the two-dimensional case and approximate the solution at discrete spatial mesh points and at discrete time periods.

Brian McNamara’s Game programming in F# (with Silverlight and WPF)

I wanted to learn more about Silverlight, WPF, and Xaml (in the context of F#, of course), so I wrote a fun little game you can play in your browser (or on your desktop). It’s a knock-off of a dozen other similar games, as you can probably tell from this screenshot

Martin Doms’s Implementing the Mandelbrot set in F#

One of my favourite things to do when learning a new language (or graphics package for that matter) is to write an implementation of a Mandelbrot set viewer. So here’s my F# version, annotated to help out anyone who is trying to get to know this language.

Dmitry Lomov’s Finer Points of F# Value Restriction

Type inference algorithms are a fascinating topic – there is an interesting and beautiful theory behind them. Today we will consider one interesting aspect of type inference in F# - it might give you a glimpse of what kind of challenges coming up with a good algorithm in this space presents, and hopefully explain away a stumbling block that F# developers occasionally encounter.

Frank is a functional reactive request/response engine for .NET applications (written in F#)

Frank is inspired by the Ruby dynamic duo of Rack and Sinatra and aims to provide the simplicity of those frameworks but utilizing the powerful functional reactive paradigm for asynchronous processing.

Steve Gilham’s Launching an F# web application inside VS2010 as if it were C#

This is a follow-up to my comments on VS launcher for F# web apps, where I can put an example of the changed markup to the F# class library project to make it act like a web project and launch a browser with your Default.aspx page when you hit F5.

Phillip Trelford’s UML Sequence Diagram: F# Script

Yesterday I fancied moving some hand drawn diagrams to mouse drawn form; but instead found myself battling against a somewhat stubborn and forgetful modelling tool. It left me wondering if there might be an easier way to do this; perhaps by separating the concern of model description from layout.

Daniel Mohl’s A Distributed Hash Table (DHT) in F#: Recursion and Pattern Matching

The simplest implementation defined in the Chord Protocol requires that each node only know about its successor node. The circle of nodes, joined by each successor node association, makes up the node cluster. In order for a node to become part of the node cluster, it must execute a join request to any arbitrary node in the cluster.

Daniel Mohl’s Interacting with RabbitMQ via F# and Symbiote

Last week, I showed how easy it is to talk to CouchDB with F# and Symbiote. In this post, I'll show how you can start interacting with RabbitMQ by adding an additional dozen or so lines of code.

Steffen Forkmann’s Solving KataYahtzee with F# and NaturalSpec

Today I’m starting a new blog post series about solving code katas in F# and with the help of my NaturalSpec project. A code kata is a programming exercise which helps to improve your skills through practice and repetition.

Robert Pickering’s Strings and F# Immutable Lists

The aim of the article is to show that this is not the case, or at least it’s not as black and white as you may think. Specifically we’re going to compare how.NET strings differ considerable in performance characteristics to F#’s immutable lists.

Andre Burdette’s F# Screencast Series

This is the first of future screencasts that I am doing regarding F# programming. In this screencast I show how to use values and functions in the F# language. Enjoy!

Neil Carrier’s A Spell-Binding Tale of Three Recursions

Tail recursive functions often involve accumulators, continuations, and other values which are not really of concern to the ultimate users of those functions. These can often be curried away or otherwise hidden from the ultimate user. This post looks at three obvious techniques for doing so (there are some more that are less obvious), the differences between the three techniques, etc.

Neil Carrier’s Driving Range Pooled Allocator

Large numbers of small allocations can be brutal on a memory management system, especially in terms of CPU time (and in terms of fragmentation on non-GC systems). This post presents an F# implementation of a pooling algorithm I’ve used for many years, and in various languages from C onwards, to solve this problem.

Julien Ortin’s Technical analysis indicators in F# – Misc and Volatility

This is part of a series on technical analysis indicators in F#, based on the multi-language TA-Lib. Quick disclaimer: some of these indicators are not verified.

Vladimir Matveev’s Nature of value restriction

Value restriction is an error that firstly makes a direct hit in the brain of non-prepared developer. It has no straight analogues in the majority of mainstream languages and thus very confusing.

Vladimir Matveev’s MailboxProcessors: Practical Application

Last time we have examined the API of MailboxProcessors. Now it is time to see, how this concept can be applied to solve real-world problems.

Doug Finke’s How to add an F# type to a PowerShell session

The PowerShell Add-Type cmdlet lets you define a .NET Framework class in your Windows PowerShell session. It supports the following languages CSharp, CSharpVersion3, VisualBasic, JScript. It does not support FSharp directly.

Mark Pearl’s F# Objects Part 1, Part 2 and Part 3

In the next few blog posts I am going to explore objects in F#. Up to now, my dabbling in F# has really been a few liners and while I haven’t reached the point where F# is my language of preference – I am already seeing the benefits of the language when solving certain types of programming problems.

Mark Pearl’s International Radio Operators Alphabet in F# and Silverlight Part 1 and Part 2

My approach was really simple. I would need a function that would convert a single character to a string – i.e. ‘A’ –> “Alpha” and then I would need a function that would take a string of characters, convert them into a sequence of characters, and then apply my converter to return a sequence of words… make sense?

Mike Hadlow’s Currying vs Partial Function Application

There’s a lot of confusion over these two terms. By myself included. But I’m pretty happy now that I understand the difference and wanted to share my newfound knowledge with you, dear reader.

Bjorn Rochel’s Kata FizzBuzz in F#

Last F# book club meeting in Munich was awesome (as usual). 2 weeks ago we decided to do a Code Kata on each subsequent meeting. This week was our first, with Kata FizzBuzz. This is what we came up with.

Jim Lehmer’s Your language ain’t worth a pair o’ dimes

That's not to say the Real World Functional Programming book is a bad book. It has been an interesting read so far, for sure. I am just going to stop reading the C# parts, thereby allowing the new concepts and new language I am learning to be "pure" in my mind, which should actually help speed up my learning process. And my suggestion to you is if you pick up the book, do the same thing, too. Dump your baggage, start fresh!

Rick Minerich’s The Ted Neward F# Folding Challenge

Take a list of numbers and compress it in a particular simple way but without any mutable state. What makes this problem interesting is that a tech interviewer mentioned that that he hadn’t seen a functional solution to this problem. I also wanted to share this because I think it’s a great example of how to convert an imperative loop into a functional fold.

Steepest Ascent Hill Climbing in C# and F#

RickM — Mon, 28 Dec 2009 19:21:09 GMT

Recently I’ve been working with some local search techniques and wanted to share my Steepest Ascent Hill Climbing solution.

The general idea of Steepest Ascent Hill Climbing is that in each iteration of the hill climbing process you apply a set of transforms to your input data and select the best result via a fitness function. This result, or the transform which created it, is then the input for your next iteration. The process stops when no transform in an iteration scored higher than the previous generation’s winner.

In this way each iterative step brings you closer to a local maxima of your fitness function’s graph. This is where the term “Hill Climbing” comes from. It is considered a relatively simple AI technique but is also is broadly applicable, quite easy to reason about and can be tweaked for many different corner cases.

For this particular example we will be assuming composable transforms. For each iteration of our hill climbing we will apply our standard transform set to the winning transform of the last round and so produce a new set of transforms.

public delegate T TransformComposer<T>(T lastT, T thisT);
 public delegate S TransformApplier<S, T>(S set, T transform);
 public delegate uint FitnessFunction<S>(S set);
 
 public class HillClimberResult<S, T>
 {
     public HillClimberResult(uint score, T transform, S set)
     {
         Score = score;
         Transform = transform;
         Set = set;
     }
 
     public uint Score { get; private set; }
     public T Transform { get; private set; }
     public S Set { get; private set; }
 }
 
 public class HillClimber<S, T>
 {
     public HillClimber(
       TransformComposer<T> composer,
       TransformApplier<S, T> applier,
       FitnessFunction<S> fitness)
     {
         TransformComposer = composer;
         TransformApplier = applier;
         FitnessFunction = fitness;
         Transforms = new List<T>();
     }
 
     public List<T> Transforms { get; private set; }
 
     private TransformComposer<T> TransformComposer { get; set; }
     private TransformApplier<S, T> TransformApplier { get; set; }
     private FitnessFunction<S> FitnessFunction { get; set; }
 
     public HillClimberResult<S, T> FindMaxima(S inputSet, T initialTransform)
     {
         if (inputSet == null)
             throw new ArgumentNullException("inputSet");
         if (initialTransform == null)
             throw new ArgumentNullException("initialTransform");
         if (Transforms.Count == 0)
             throw new ArgumentException("No transforms were set.");
 
         HillClimberResult<S, T> best;
         HillClimberResult<S, T> iterBest = ApplyTransformAndScore(inputSet, initialTransform);
 
         do
         {
             best = iterBest;
             foreach (T transform in Transforms)
             {
                 var nextTransform = TransformComposer(best.Transform, transform);
                 var result = ApplyTransformAndScore(inputSet, nextTransform);
                 if (iterBest.Score < result.Score)
                     iterBest = result;
             }
         } while (iterBest.Score > best.Score);
 
         return best;
     }
 
     private HillClimberResult<S, T> ApplyTransformAndScore(S inputSet, T transform)
     {
         var transformedSet = TransformApplier(inputSet, transform);
         var score = FitnessFunction(transformedSet);
         return new HillClimberResult<S, T>(score, transform, transformedSet);
     }
 }

I like the way this worked out in C# quite a lot. However, take a moment to compare it to a F# version I quickly whipped up:

type HillClimber(composer, applier, fitness, transforms) =
     member x.FindMaxima initialSet initialTransform =
         let maxOfScores one two = if fst one > fst two then one else two
         let findBestTransform set lastTransform =
           transforms
             |> List.map (fun(transform) -> composer lastTransform transform)
             |> List.map (fun(transform) -> applier set transform, transform)
             |> List.map (fun(transformedSet, transform) -> (fitness transformedSet), transform)
             |> List.reduce maxOfScores
         let rec climb set lastScore lastTransform =
             let (thisScore, thisTransform) = findBestTransform set lastTransform
             if thisScore <= lastScore then (lastScore, lastTransform)
             else climb set thisScore thisTransform
         climb initialSet (fitness initialSet) initialTransform

It’s quite shocking how much less code is necessary. However, there is a small problem with this example. As we are not using HillClimber from inside of its own library, all of its function inputs resolve to System.Object. The solution is to simply do a bit of annotating to ensure that compile time types are as generic as possible.

type TransformComposer<'t> = 't -> 't -> 't
 type TransformApplier<'s,'t> = 's -> 't -> 's
 type FitnessFunction<'s> = 's -> float
   
 type HillClimber<'s,'t>(composer: TransformComposer<'t>, applier: TransformApplier<'s,'t>, fitness: FitnessFunction<'s>, transforms: list<'t>) =
     member x.FindMaxima initialSet initialTransform =
         let maxOfScores one two = if fst one > fst two then one else two
         let findBestTransform set lastTransform =
           transforms
             |> List.map (fun(transform) -> composer lastTransform transform)
             |> List.map (fun(transform) -> applier set transform, transform)
             |> List.map (fun(transformedSet, transform) -> (fitness transformedSet), transform)
             |> List.reduce maxOfScores
         let rec climb set lastScore lastTransform =
             let (thisScore, thisTransform) = findBestTransform set lastTransform
             if thisScore <= lastScore then (lastScore, lastTransform)
             else climb set thisScore thisTransform
         climb initialSet (fitness initialSet) initialTransform

Of course, it would be great if the F# type system would reduce to generics instead of System.Object in this case. I would think the ideal would be to always reduce to the most generic type possible. I’ll have to give it a try tonight with the latest VS2010 beta and see if there is any improvement.

Continuing on, let’s give this a go with something simple. We know that the maximum value of |A| – A^2 is 0.5, –0.5. Can we climb our way to one of these values?

#load "HillClimber.fs"
 open HillClimber
 
 let composer last next = fun x -> (last x) + (next x)
 let applier set transform = transform set;
 let fitness x = abs( x ) - (x ** 2.0)
 let transforms = [fun x -> x + 1.0; 
                   fun x -> x - 1.0;
                   fun x -> x + 0.1;
                   fun x -> x - 0.1;
                   fun x -> x + 0.01;
                   fun x -> x - 0.01]
 
 let climber = new HillClimber<float,float->float>(composer, applier, fitness, transforms)
 
 let initialValue = 0.0
 let (score, transform) = climber.FindMaxima initialValue (fun x -> x)
 let result = transform initialValue

…Highlight, Alt-Enter…

val composer : ('a -> float) -> ('a -> float) -> 'a -> float
 val applier : 'a -> ('a -> 'b) -> 'b
 val fitness : float -> float
 val transforms : (float -> float) list =
   [<fun:transforms@10>; <fun:transforms@11-1>; <fun:transforms@12-2>;
    <fun:transforms@13-3>; <fun:transforms@14-4>; <fun:transforms@15-5>]
 val climber : HillClimber.HillClimber<float,(float -> float)>
 val initialValue : float = 0.0
 val transform : (float -> float)
 val score : float = 0.25
 val result : float = -0.5

Looks good!

Well, it looks like that took a bit longer than I had anticipated. I’ll be back with my weekly update tomorrow.

F# - Designing Functional Interfaces for Pipelining

RickM — Thu, 12 Nov 2009 18:58:09 GMT

So you have an Object Oriented library but yet want to be able to use F#’s functional pipelining feature to design expressive data processing workflows. How do you go about it?

First, lets set a goal. Some low hanging fruit so to speak. Let’s pretend we have a set of images we want to load, resize, intensify and save as Png files for later use in an online image gallery.

Image Processing In C#

For reference, this would look something like the following using our DotImage toolkit in C#:

public void ProcessImage(string fromfile, string tofile)

{

ImageCommand[] commands = new ImageCommand[] {

new ChangePixelFormatCommand( PixelFormat.Pixel8bppIndexed ),

new ResampleCommand( new Size( 800, 600) ),

new IntensifyCommand( 50.0 )

};

AtalaImage currentImage = new AtalaImage(fromfile);

foreach (var command in commands)

{

currentImage = command.Apply(currentImage).Image;

}

currentImage.Save(tofile, new PngEncoder(), null);

}

It’s a testament to the skill of our Senior Architect that this task is as simple as it is in C#.

Note: our image representation is IDisposable and for optimal performance should immediately be disposed when done being used. I’ll be covering how to leverage F#’s type system to handle this in a later post.

Now, in F#

In comparison, this is how I envision this same process using F#’s functional pipelining style:

let processImage infile outfile =

Image.fromFile infile

|> Image.changePixelFormat Image.PixelFormat.Pixel8bppIndexed

|> Image.resample 800 600

|> Image.intensify 50.0

|> Image.toPngFile outfile

These pipelined functions are so easy on the eyes. It’s immediately obvious what’s going on here. Unfortunately, it can be rather difficult to use pipelining with non function constructs.

Wrapping an Object Oriented Library for Pipelining

To bring this seamless integration with F#, we must first wrap these Object Oriented classes so that they can be used in a functional way. This is a rather simple task:

namespace Atalasoft.FSharp

open System.Drawing

open Atalasoft.Imaging

open Atalasoft.Imaging.Codec

open Atalasoft.Imaging.ImageProcessing

open Atalasoft.Imaging.ImageProcessing.Filters

module Image =

type image = Atalasoft.Imaging.AtalaImage

type PixelFormat = Atalasoft.Imaging.PixelFormat

let fromFile (filename: string) =

new image( filename )

let toPngFile (filename: string) (img: image) =

img.Save( filename, new PngEncoder(), null) |> ignore

let resample (width: int) (height: int) (img: image) =

let newSize = new Size( width, height ) in

let cmd = new ResampleCommand( newSize ) in

cmd.Apply(img).Image

let intensify (magnitude: double) (img: image) =

let cmd = new IntensifyCommand( magnitude ) in

cmd.Apply(img).Image

let changePixelFormat (pf: PixelFormat) (img: image) =

let changer = new AtalaPixelFormatChanger() in

changer.ChangePixelFormat(img, pf, null)

So, in this way, we can define modules which will hide our object oriented interfaces. However, let’s take a deeper look. There are a some important things to keep in mind when designing functions for pipelining.

First, observe that the module definition encapsulates all of our pipelining functions and mandates how they will be accessed later. It is good design practice to define all pipelining functions for the same type within one module. This module should have the same name as the type but with the first letter capitalized.

Second, notice that we use type abbreviations to create local versions of the AtalaImage and PixelFormat types. This makes our library code easier to read and allows us to use the F# lowercase type naming style. Even more importantly, by defining all exposed types in this way the consumer of this module will not need to open any namespaces from the assemblies we are wrapping.

Third, see how image is the last parameter to each function? To be able to pipeline into a function its final parameter must be of the to-be-pipelined type.

Note: This is not strictly true. If you wish to pipeline into a function and then return a function with that value curried in, it can have additional parameters which will be filled in later. However, that’s a topic best left for another time.

Finally, note that the return type of each of the intermediate image processing functions is also image. This ensures that the output can be pipelined directly into the next function.

Our F# Wrapper in Action

Let’s highlight the contents of this fsx file, hit alt-enter, and give it a whirl in the F# Interactive Window:

#r "Atalasoft.dotImage"

#r "Atalasoft.dotImage.Lib"

#r "Atalasoft.Shared"

#load "Image.fs"

open Atalasoft.FSharp

let processImage infile outfile =

Image.fromFile infile

|> Image.changePixelFormat Image.PixelFormat.Pixel32bppBgr

|> Image.resample 400 300

|> Image.intensify 70.0

|> Image.toPngFile outfile

Finally, in F# Interactive we can simply type:

> processImage @"C:\temp\Water lilies.jpg" @"C:\temp\Water lilies.png";;
val it : unit = ()

and we have our processed image:

Conclusion

Of course, this implementation leaves much to be desired. It hides the vast majority of the available functionality in our underlying library. Taken to it’s natural end it leaves us with the unfortunate task of wrapping our entire library one command at a time, which is hardly an appealing prospect.

What if you wish to leverage existing objects without wrapping each individually? Well, we will explore that next time.

Discoveries This Week 05/24/2009

RickM — Mon, 25 May 2009 02:24:00 GMT

An exciting week with the release of Visual Studio 2010 Beta 1 and F# 1.9.6.16. This week we have John Backus’s classic FP manifesto, Luke Hoban speaks on F# in VS2010 beta 1, Django for ASP.NET, and an article on breaking changes in the latest F# release.

John Backus – Can Programming Be Liberated from the von Neumann Style?

Functional programs deal with structured data, are often nonrepetitive and nonrecursive, are hierarchically constructed, do not name their arguments, and do not require the complex machinery of procedure declarations to become generally applicable.

The functional programming manifesto. Well worth the time to read for anyone serious about functional programming.

Luke Hoban on Channel9 – What’s the Story? What’s Next?

Here, F# Program Manager Luke Hoban talks with me about F#, generally and what people have been doing with it, the current state of the technology, what F# enables

The most interesting thing I gleamed from the talk is that F# Powerpack will not be included with Visual Studio 2010. Luke hopes that this will allow faster development cycles.

Alex Pedenko’s Project, NDjango - Django templates in .NET

The current version is being released as a beta. It has full django tag support, and most of the default filters.

I’ve heard many great things about Django from my web developer friends. I’m sure many will be happy to see ASP.NET support. It can be used stand-alone or in conjunction with the Bistro Framework. Best of all, NDjango is built on F# and Bistro has full F# support.

Abel Avram on InfoQ - Latest F# Breaks Binary Compatibility

Microsoft has included F# in VS 2010 Beta 1 and has released a corresponding CTP update for VS 2008. The latest binaries, version 1.9.6.16, are not compatible with previous ones, v. 1.9.6.2, meaning all previous code needs to be recompiled.

Also important to note, the #light syntax is now on by default.

I understand it is exceedingly painful to sign up for an account to leave a comment. That given, I am still trying to figure out a solution to my spam problem. For now, if you would like to comment and don’t wish to set up an account, please email me your comment and I will manually post it.

Discoveries This Week 03/20/2009

RickM — Sun, 22 Mar 2009 20:09:43 GMT

This week there seems to be quite a bit of video and audio content to share. We have a dramatic depiction of the benefits of Units of Measure, Luke Hoban on F#’s feature, Ted Neward talks about F# under the hood and finally a discussion on operator type inference.

Video Blog – Could F# have saved the Mars Climate Orbiter?

A fantastic example of how static dimensional analysis of scalar values could prevent an entire class of bugs. In the past, I’ve talked about what a huge fan I am of the Units of Measure package for F#. I’m glad that others also see how revolutionary units of measure are.

Would you want to work in a building or live in a house in which the engineers who built it did not keep track of units? I don’t think anyone would answer yes. Similarly, we should not entrust our lives or livelihoods to software in which these very same things are not kept track of.

Podcast – SER Episode 129 - F# with Luke Hoban

In this podcast Luke Hoban, the F# program manager, discusses about various aspects of F#.

Some highlights:

Mutability comes along with .NET Framework support.
Statically Typed means strong guarantees and so robust systems.
FP design in the small for concurrency
OO design in the large for scalability
Explorative programming via interactive window
Influenced heavily by Haskell
FP as a technique, not a class of languages

Video Blog – dnrTV Show #136: Ted Neward Introduces F#

Ted Neward gives an in-depth presentation on both how F# works under the hood and the general benefits that stem from FP in general. The examples used are simple but Ted covers them in a very exhaustive way.

Beyond the language and concepts therein, he also has a number of insightful comments about teaching people to use F#. In particular the idea that F# syntax will be easy to teach but functional programming technique will take years really struck home with me.

Blog – Kalani Thielen’s The F# overload-o-phone

In his post Kalani points out a small but significant logical inconsistency in F#’s type inference system. The issue seems to stem from the way type inference is handled for basic operators. Instead of working generically, they each have default types.

From his post:

> (+);;
val it : (int -> int -> int)
> 3.2 + 5.4;;
val it : float = 8.6
> let twice x = x + x;;
> twice 9.4;;
stdin(2,5): error FS0001: This expression has type
float but is here used with type int.

To get around this, he then goes on to build a function which takes an operator and both arguments. However, this workaround is completely unnecessary. You need only to annotate the function’s input and it works without issue.

> let twice (x: double) = x + x
val twice : double –> double
> twice 9.4;;
val it : double = 18.8

Now, it’s important to note that this version of the twice function won’t accept an integer. In fact, it was a conscious design decision to disallow function overloading in F#. In both F# and C# all kinds of overloading must be qualified by type. That is, type methods support argument overloading but free floating functions do not.

What Would You Want From a F# User Group?

RickM — Thu, 12 Mar 2009 13:39:00 GMT

Michael de la Maza, Talbott Crowell and I are all very excited about finally getting our F# User Group off the ground. However, as F# groups are currently few and far between, we are very interested in finding out what attendees would want from such a group.

Where and When?

In terms of broad time frame, we are looking at having our first meeting in April. We currently have a few options open in terms of which day of the month. If you are interested in attending, head on over to our doodle poll and tell us which days would be best for you.

The group will be held at the new Microsoft NERD center in Cambridge, Massachusetts. A big thanks to Chris Bowen for helping us find such an exciting place to hold our meetings. I know that I’m not the only one hoping that some of the Microsoft research NERDs will have time to come down to our meetings.

Online Content?

We are planning on recording each meeting and putting the videos up online. We don’t have the hosting solution for this firmly pinned down yet, however there are a large number of different options available. Our criteria are support for video of at least two hours in length and high resolution. Ideally, we would like to use a Microsoft-based solution.

Types of Meetings?

While most .NET user groups seem to be primarily presentation based, they are often much more broadly scoped and targeted at an audience with deeper topical knowledge. For these reasons we are considering a number of different formats for the group.

F# Boot Camp - The focus of this type of session would be getting developers who were new to F# and/or FP started. This might include a small presentation, some group activity work and, finally, an open discussion forum.
Presentations - We are working on bringing in F# experts to present on related topics. This will be via both physical presence and remote conferencing.
Competitions - I love competitive coding and I think that there’s no better way to get people excited about a topic. These competitions would likely be web-based and open to all F# users.

Our goal is provide interesting content for both those new to F# as well as those with some experience. As F# is a fairly new language, it’s reasonable to assume that news attendees will have a low level of previous exposure to the language. Due to this, our current thinking is that it would generally be best to start with the basics and work our way up to more advanced topics over time.

Let’s Wax Functional 03/06/2009

RickM — Sat, 07 Mar 2009 23:09:00 GMT

This week we have MapReduce, WebTools and yet another F# to C# language comparison. I spent yesterday at a seminar led by Michael de la Maza. He, Talbot Crowell and I will soon be starting a F# user’s group in Boston, Massachusetts. I’m interested in any comments you might have. Please feel free to send me an email if you would like to discuss speaking at it or content you would like to see covered.

Blog - Matthew Podwysocki’s Exploring MapReduce with F#

Google’s MapReduce software framework has revolutionized the way software engineers think about processing large data sets. Since it’s introduction at least 15 variants have been developed. Thorough as always, Matthew explores what MapReduce is, how it relates to functional programming and, finally, shows his own light-weight MapReduce implementation.

Software – Thomas Petricek’s FSharp.WebTools

The F# Web Tools augment the F# distribution with tools to author homogeneous client/server/database web applications in one type-checked project.

It does this by generating Javascript from F#. The big advantage here is that you can effectively have statically checked Javascript and so avoid a whole class of bugs that come along with dynamically typed programming. While many are excited about this prospect, at least one person seems to have had trouble getting it to work. Currently, only the source tree is available and it must be manually compiled. I know I’m not the only one hoping for a tested release in the near future.

Blog – Martin Peck’s Solving Problems in C# and F# – Part 1

In this post Martin compares solutions to Project Euler problems 10 and 12 in both C# and F#. In competition with his friend Giles Knap, he wrote his answers in C# while Giles wrote in F#. Afterward, each set of answers is discussed independently. He concludes that the languages were equally readable but the F# implementations were slower.

I wish Giles had written a rebuttal post as Martin seems to be a die hard C# fan. I don’t agree that they were equally readable. The F# problems lacked much of the syntactic cruft and whitespace found in the C# examples.

Also, as single core results are fast becoming meaningless, it would be very if they would agree to use asynchronous workflows in F# and compare that with the .NET Parallel Extensions in C#. By constraining the answers to be single thread only, it seems like they avoided much of F#’s inherent benefit in multicore processing.

I also can’t help wondering how each of their prime generating examples would compare with the memoizing example I mentioned two weeks ago. I’d be shocked to see a similar C# implementation in anywhere near as little space.

Why OO may not suck, or, Take a ride on the Falsus Omnibus

RickM — Wed, 11 Feb 2009 11:00:00 GMT

This post is in response to Joe Armstrong’s Why OO Sucks. While I feel that Joe’s post reads more like an sermon than a stream of rational thought, it does bring up a number of misconceptions I feel many people in the functional programming world share and which need to be discussed openly if it and the object oriented world are to come to terms and work together.

The main issue here is that, in the minds of many functional programming advocates, the concept of an object is inseparable from the amalgamation of 30 years of different, and sometimes contradictory, object oriented programming ideologies.

Perhaps they don’t understand that when binding these ideas together for the sake of argument they are simply constructing a straw man. Similarly, to say that we must either have all of the history of object oriented design or pure functional programming, is a false dichotomy. We can have either, neither, both separately, or any number of combinations of ideas from both groups.

Now, lets address each of Joe’s objections from a somewhat more moderate perspective.

In Response to “Objection 1 – Data Structure and functions should not be bound together.”

I disagree with Joe’s logic here. It does not follow that because functions and data structures are “different animals” that they should “not be kept in the same cage”. Wouldn’t having functions be first class citizens be locking them in the same cage with data structures as well? The fact that they do share some fundamental similarity is manifest in that most functional programming languages do not treat function and data structure in a fundamentally different way.

Also, I have seen no compelling reason as to why it is wrong to couple transformations with the data structure that they are able to be applied to. When transformations often have to be tailored specifically for a particular data structure, why would we not keep them strongly associated with said data structure.

In Response to “Objection 2 – Everything has to be an object.”

As I discussed in my introduction, this is simply not true in all languages which support objects.

In Response to “Objection 3 – In an OOPL data type definition are spread out all over the place.”

First of all, it should be immediately obvious to anyone who works on even medium sized projects that having many types defined in the same file is a very bad thing. The core of the issue is that it makes group collaboration quite difficult.

Secondly, any system that has ubiquitous data structures can’t be very large otherwise the namespace would become quite cluttered. In large systems this cannot be mitigated by simply saying “more functions, fewer data structures”.

Finally, to state that any object which operates on another must inherit from it is a completely incorrect statement. In the modern object oriented world it is common to have objects which exist solely to build, process or interface with other objects. Also, as I mentioned above, it’s entirely possible to have stateless objects which are simply data structures which are bundled with a collection of predefined transformations.

In Response to “Objection 4 – Objects have private state.”

First of all, state is not the root of all evil. While it may be harmful to concurrency and static analysis, there are many stateful algorithms which perform much better than their stateless counterparts.

Secondly, it’s entirely possible to have immutable objects. Perhaps in these objects some state is hidden for the sake of representing ideas in a simple manner, perhaps not.

Finally, as to information hiding in general, in large systems it’s very easy to be overwhelmed by the quantity of information. If you can say via testing “I can trust this structure over here” it means it’s entirely possible to ignore that and focus work on another piece of the system. It’s also important to note that functional programming languages often have information hiding systems of their own. In the most base case, calling other precompiled functions amounts to information hiding and comes along with all of the negative things stated in this section.

In Response to “Conclusion – Why OO was popular.”

It seems to me here that if you removed all instances of “It was thought” this would be a somewhat correct summarization.

In reality, the industry has been using object oriented programming for many more reasons than what has been listed here. A particularly strong reason is that it supplies an organizational framework for data structures and functions which simply does not have an equivalent in the pure functional programming world.

Conclusion

I must apologize to Joe here. I don’t intend to pick on him in particular. However, I had never previously seen a post in which the the most common misconceptions around object oriented programming were so plainly stated.

To say that the concept of an object and that the collections of ideologies used commonly to construct programs using objects are somehow inseparable is completely false. To further state that the only reasonable choice is to instead move to pure functional programming bears no additional truth. Yet they are both pieces of constantly perpetuated misinformation.

The fundamental idea that data and function can be bound for the sake of organization still holds and does not inherently violate any of the tenants of functional programming. In terms of the organizational structure of our programs we have gained much from objects. Why then should we abandon them without sufficient reason? It seems to me that it would be a mistake to dismiss all of what we have gained for baseless ideological reasons alone.

Discoveries This Week 02/06/2009

RickM — Fri, 06 Feb 2009 16:24:00 GMT

Some interesting gems this week. Revit, Closures and MathTools won the day. However, I do hope you'll take a look at the IL post as well.

Blog – Jeremy Tammik’s Use F# Directly in Revit

In Jeremy’s post he discusses what is initially necessary to get F# and Revit working together. He also provides a sample of a Revit addin written in F#.

Revit is Autodesk’s architecture and design studio. It allows physical engineers to coordinate and play with, design and visualize data while integrating directly with AutoCad. It also provides a .NET 2.0 API. Given F#’s support for units as well as it’s concise and mathy style, it makes sense that it would be an ideal language for engineers.

Site - WikiBooks FSharp Programming

Before I stumbled upon this site, I had never head of of WikiBooks. That’s why I was incredibly surprised to find that it has the best online general F# reference around. It has extensive sections on functional, immutable and imperative programming with rich examples and references to the math behind the ideas presented. It’s a great site to have at hand for both those learning about the language and those experienced but still needing to occasionally look something small up.

StackOverflow - A practical example of a closure in F#

Learning how to program functionally is much more than just learning some new ideas and a new syntax. It comes along with a ton of new jargon, some of which can be quite foreign sounding. I find that it often turns out that the jargon actually represents a very simple idea and that becomes immediately obvious when discussed with a simple example.

Software – FSharp.MathTools

As you might have suspected by its name, MathTools is an extensive set of mathematics libraries for F#. It provides, among other things, statistical functions, fast fourier transforms, optimization algorithms, Matlab compatibility and extended mathematical notation. With a little development this combined with VSLab could provide a viable alternative to tools like Matlab while still allowing for collaboration with colleagues.

Article – Introduction to IL Assembly Language

It’s the responsibility of any serious programmer to know how how his or her tools work all the way down the chain. In this relatively short article (given the topic) everything you would need to write a .NET compiler is distilled. It’s the best reference of it’s kind I’ve seen.

Discoveries This Week 01/30/2009

RickM — Fri, 30 Jan 2009 19:46:55 GMT

The beauty of clean syntax and deep abstraction is an often overlooked feature of functional programming. As they say, people come to functional programming for the concurrency but stay for the beautiful code (actually, I just made that up). Also included: POPL 2009, S#arp and functional unit testing.

Blog - Matthew Podwysocki’s Series on Functional Unit Testing

In this eight part series Matthew covers unit testing in Haskell from the basics setting up HUnit to the details of writing purely functional tests.

This series is the only place where I’ve seen functional programming unit testing talked about with any significant depth. While in writing this series Matthew used Haskell, it and F# share much in common and it’s obvious that he worked hard to make his posts apply to both. I consider it a must read for anyone thinking about taking functional software engineering seriously.

Although he has finished the series, I hope that in the future he takes some time to focus on unit testing in F# specifically. I’ve yet to see topics such as mocking or ensuring referential transparency by test covered.

Transcription - POPL 2009 Grand Challenges Panel Summary

This panel was lead by such research giants as Simon Peyton Jones, Xaveir Leroy, Kathryn McKinley, Greg Morrisett and Arvind. In it they discuss where programming language development is heading and the factors driving us there. Well worth the read for anyone interested in programming language evolution.

Blog - Mark Needham’s F# vs C# vs Java: Collection Parameters

In this post Mark compares list operations in F#, C# and Java. It’s striking to see how far we have come in terms of clean, concise syntax. Actually, it seems kind of reminiscent of evolution of man posters.

Blog - Jafar Husain’s F#: Real Sharp

When working in F# over a long period it’s easy to forget that one of the best things about it is how it’s concise syntax and deep abstractions make your code so much easier to understand and beautiful to look at. In his post Jafar reminds us of this by contrasting C# with F# samples.

Software – S#arp Architecture Beta 1.0 Available

S#arp Architecture promises to make building web applications much easier by making much of the glue we currently use in ASP.NET web applications obsolete.

I am a big fan of inversion of control and it is something that comes very natural in functional programming languages. I hope to see some examples with S#arp Architecture and F# internals at some point in the near future.

F# and Haskell, Estranged Cousins

RickM — Thu, 29 Jan 2009 20:24:00 GMT

In this post I compare and contrast Haskell and F#. It may come as no surprise that with so much shared history they share so much in common. However, it’s interesting to consider how the perspectives of the languages’ developers play a large role in determining the differences between the languages.

A Shared History

As far as the family tree of functional programming is concerned, F# and Haskell are not too distant cousins.

They both share a very similar syntax as well as a large number of features. A great example of this is Hindley–Milner type inference.

ML was the first widely used language to leverage Hindley–Milner for static inferred typing, a feature to which it owes much of it’s success. However, almost all functional programming languages now also have this feature. The FP community has always been fast to adopt obviously useful features. Some other things that fit into this category are garbage collection (Lisp) and lazy evaluation (Lazy ML).

The most obvious difference between Haskell and F# is somewhat easy to infer from this graph: object oriented constructs. That is to say, OCaml pioneered the use of object oriented data structures in functional programming and F# is it’s direct descendant. This has made OCaml (and in turn F#) somewhat of a black sheep in the theoretical functional programming world.

The reason many functional programming theorists dislike objects is because they want a language based on math. Unlike the majority of the ideas in functional programming, objects don’t have roots in either lambda calculus or category theory. However, this has not stopped OCaml from being successful. In fact, quite the opposite.

The use of objects mitigates one of the largest roadblocks in the path to functional programming adoption by engineers: the difficulty inherent in organizing large functional programs. The OCaml language engineers also showed that leveraging the object oriented paradigm did not hamper their ability to use static analysis techniques. Because of this OCaml approaches the speed of C.

While it is not pure, OCaml is almost an ideal compromise between theory and engineering. Indeed, nothing approaches it in terms of a functional language which fits into the paradigms of the Microsoft .NET framework. It’s easy to see why Microsoft chose to extend OCaml when building a functional language to bring to it’s software engineering masses.

On the other hand, Haskell is almost the ideal language for academic exploration of functional programming. The fact that it’s strictly limiting in terms of side effecting and adherence to abstract mathematical concepts means no side effecting surprises. Also, the fact that it’s a committee language means that if a researcher can get enough support for an idea, they can almost be sure it will be included in the next iteration of the language.

Haskell as a Committee Language

Repeat the mantra after me: Haskell is Lazy; Haskell is Pure; Haskell has Type Classes; Haskell is a Committee Language.

Of all of these, the most defining characteristic of Haskell is that it is a committee language. It’s an amalgamation of many different goals with no clear vision. This is at the same time Haskell’s greatest strength and greatest weakness. While it is the most widely used pure functional programming language, the quirks of committee design are obvious.

Some I ran into within two hours of starting with Haskell:

The first was integer rollover. Haskell has two integer datatypes: integer and int. Integer is infinitely sized but can be quite slow to use and due to that, it’s rather infrequently used. On the other hand int is fast but, just like in C, can roll over. There is no way to check the overflow bit.

So, ints can roll over, I can accept that. What it implies to me is that speed is more important to Haskell than robustness. However, this brings me to my second point: Many basic list operations will throw errors on an empty list. This seems entirely inconsistent to me.

I understand that if they didn’t, a logic error would be much more likely to cause an infinite loop in a tail recursive function. However, this seems completely at odds with the “speed first” definition of an int. It also means that almost everyone ends up wrapping the default list operations with the Maybe monad.

The third issue was that operations with the float data type are slow. Real World Haskell suggests always using a double due to the fact that a great deal of focus has gone into optimizing double arithmetic but very little into floats. This demonstrates another thing that comes about with committee languages: often things as important as optimization of basic data types can fall through the cracks because everyone involved wants to work on more exciting things.

Please don’t misunderstand me here, I really like Haskell. I’m hard on it because I can see that it has a great deal of unrealized potential. If Haskell is to be a language used for real software engineering, the committee needs to sit down and think hard about an overarching vision for the project.

What is the goal here?

The biggest difference between the world of theorists and the world of engineers is that each group has an entirely different set of concerns.

Theorists want to implement ideas fast so that they can crank out papers fast. A large part of this is having a language that is very close to math so that implementing ideas directly from the chalkboard is trivial. As the theory world changes so fast, they don’t often care much about organization or maintainability.

As the committee responsible for Haskell is mainly made up of theorists, it’s easy to see why the language has taken the direction it has. It’s a language that is very close to math. As the lifecycle of most academic code is very short, small implementation details which might cause a reduction in robustness are less important.

Engineers want to minimize time spent maintaining code. Part of this is having a language that emphasizes safety in that it facilitates catching as many bugs as possible, as early in the process as possible. Another important part of this is code organization as every moment that is spent trying to find a bug is a moment spent not fixing it. As the cost of maintaining software generally dwarfs the initial development cost, development speed must take a back seat to testing and organization.

The syntax heavy C# is a great example of this. It’s slow to write in but provides many constructs for the organization and testing of code. On top of this a great number of design patterns exist to further categorize substructures in a computer program. C# is slow to write, but it’s relatively safe and mountains of patterns and best practices have been made to guide it’s developers.

However, we in the software engineering world are in the midst of a crisis. It turns out that traditional imperative object oriented programs do not lend themselves to heavy parallelization. Yet, parallelize we must. We are looking at exponential growth in the number of cores contained in each processor. Because of this we engineers find ourselves at a bit of an impasse. Those that are looking ahead know…

Engineers will soon want very badly to minimize time spent maintaining parallelized code. We need our programs to be easy to organize, manage and test. Yet, as we will soon need to deal with massively parallelized systems, we find many of our ideas about what makes code robust and maintainable are broken. At the same time, to move to a purely functional language means leaving behind years of thought on how computer programs ought to be constructed, tested and maintained. Having any pattern, even if it’s wasteful or has many corner cases, is much better than having none. This is why a hybrid language is so important.

OCaml and F# provide engineers with the set and forget concurrency that comes along with the functional tradition. At the same time these languages have all of the organizational constructs of object oriented programming as well. This means that we can continue to use the same types of large scale organizational structures in our programs and also gain the safe parallelism that implicit immutability provides.

Conclusion

And so we see that it’s important to consider a language in terms of how it’s creators envisioned it’s use. Haskell has been developed mainly with research in mind and so is a fantastic research language. F# has been developed mainly with engineering in mind and so is much better suited for engineering.

In understanding this it’s also easy to see that comparing Haskell to F# is like comparing the tools of a physicist to those of an engineer. They may have much in common superficially, but they are designed with much different ends in mind.

Links

A History of Haskell: Being Lazy with Class
Tutorial: OCaml for Scientific Computation (Contains some history)

Discoveries This Week 01/16/2009

RickM — Fri, 16 Jan 2009 16:17:00 GMT

This week’s theme is functional programming. Included are discussions on Software Transactional Memory, Functional Architecture and the impact of the CLR on functional Programming in .NET.

Blog: Brandon Werner’s Software Transactional Memory: Debunked!

In starting with a title that is decidedly sensationalistic, Brandon effectively trashes STM over its expensive overhead based on a paper published by ACM. His position, and that of the researchers, is that most programmers see assignment as inexpensive and so would not understand that they need to optimize for atomic transactions when using STM.

Brian Hurt responded at length in his blog post The Problem with STM: your languages still suck. Brian’s view is that the fundamental issue here is that most programming languages encourage heavy use of mutable variables and so many expensive assignments and reads are happening when STM is used. If instead one is using a functional programming language which discourages variable mutations, the high cost of STM is much less of an issue. Brian then further flushes out his ideas in a follow up blog in which he responds to responses to his first.

While I don’t agree that ACM’s analysis “puts a deep nail in the coffin of STM”, I also don’t think it’s reasonable to expect most programmers will be jumping on the functional programming bandwagon in the near future. The main issue is that it’s just too different from what they are used to.

For now FP will remain the domain of the motivated and pragmatic programmer. It will be necessary to slowly ease the majority into this new, different world via things like functional C# extensions. I do think that some kind of STM with training wheels for mainstream programmers would be a good way to promote this over the long term. However, it would be extremely important that the inherent overhead is explicitly stated.

Finally, I wanted to note that Sasha Dadiomov of the Microsoft STM team has an interesting piece on the difficulties involved in debugging STM. It’s an informative glimpse of how Microsoft’s implementation of STM is shaping up.

Blog: Chris Smith’s Speech Recognition is gun [sic] and easy!

It’s possible he meant fun and easy but I can’t be sure.

A quick but fun piece on leveraging System.Speech.Dll inside of F#. The result is a 10 line program that takes your speech as input and prints it to the console. Very simple yet quite cool.

Blog: Matthew Podwysocki’s How would the CLR Be Different?

In this post Matthew discusses how the CLR might be better implemented to serve the needs of functional programming languages. I especially like the idea of including some new functionality for type manipulation and construction.

However, I would like to see specific examples of exactly what Matthew would like changed under the hood. He mentions a lot of general goals with reasoning to back them up but not how they might be implemented. I also feel that it would be inappropriate to implement some of these ideas at the CLR level instead of the language or API level.

For example, non-null references. I’m all for Spec# style pre and post conditions but why is it necessary that this be implemented at the CLR level? This belongs in the language instead. Also, the issue with immutability in .NET mostly has to do with Microsoft’s .NET API design. The stack based nature of IL is completely compatible with the idea.

The CLR should be designed with the most general case in mind and not with the slant towards any particular language. If the CLR is to be viable long term, flexibility must be emphasized over specific optimizations.

Paper: Sebastiaan Visser’s Building a Wiki in Haskell

A study on implementing a Wiki in Haskell which is a purely functional programming language. This paper is a must read for both those interested in functional project architecture and those who question the viability of using FP for large applications. The complete source of the project is available for your viewing pleasure.

Discoveries This Week 01/09/2008

RickM — Fri, 09 Jan 2009 16:37:00 GMT

It’s been a very exciting week. I actually had more things to post than time would allow me to write about. I’ll have to save them for next time. Blog: Daniel Spiewak’s What is Hindley-Milner? (and why is it cool?) Hindley-Milner is the algorithm all...(read more)

F# at Code Camp 10 In Waltham, MA

RickM — Fri, 19 Sep 2008 20:02:00 GMT

I'll be at New England Code Camp 10 tomorrow giving another talk about functional programming and concurrency in F#. It will be fairly similar to my previous talks in terms of ideas and content, however, I have put a lot of work into making the functional programming ideas easier to understand. The code samples have also been updated and are now 100% compatible with the F# CTP Release.

~~Our internet connection is going down soon for testing. I'll be updating this post later on tonight with more information. I'll be posting my slides and updated code examples.~~

I did manage to get my slides and new code samples uploaded on Friday but I didn't have time to change my blog text. You can find them here.

The sites of interest for my presentation:
Microsoft's F# Developer's Center ( Download F# here. )
F#'s Microsoft Research Site
hubFS: THE place for F# ( The forums here are a great resource. )

Here are some additional links you might find interesting:
Don Syme's Blog
Robert Pickering's Blog
Matthew Podwysocki's Blog
My F# Ant Colony Work

How to set up your own free VSLab-based Matlab/Mathematica replacement

RickM — Mon, 08 Sep 2008 14:48:00 GMT

VSLab has just been updated with full support for Visual Studio 2008 Shell and the F# CTP release. It has been a rough couple of weeks for the VSLab team as F# CTP changed a number of things and they have been working hard to put together a compatible release. In this article I talk about a bit about what exactly VSLab is and walk you through creating a free VSLab installation.

What is VSLab?

VSLab is a Matlab-like interactive environment which is implemented on top of Visual Studio 2008 and F#. It is designed to speed the development of scientific applications and make visualizing data quick and easy. One of the great benefits, besides being free, is that VSLab allows you to compile your applications into binaries which can be easily redistributed. Also, because the code is being run on the CLR it is, in most cases, much faster than the notoriously slow Matlab and Mathematica.

The F# CTP was updated a few days ago in order to fix a number of bugs. Even if you aren't interested in VSLab, now would be a great time to update your CTP installation.

VSLab Quick Installation Instructions

With these two releases it's very easy to create your own free Matlab-Like Visual Studio environment. It's important that these steps are performed in order as each step depends on the previous step. Installing Managed DirectX is not strictly necessary but you will not be able to use the VSLab visualizations without it.

Prerequisites
If you already have a version of Visual Studio 2008 installed, it must be updated to SP1 before you can continue. The SP1 update package is available here.

All previous versions of F# and VSLab must be uninstalled before starting this process. Also, these steps must be followed in the order they appear here.

1) Install Visual Studio 2008 Shell.
1a) Download Visual Studio 2008 Shell (integrated mode).
1b) Run the installer to Extract VS 2008 Shell Package to a temporary directory.
1c) Inside that directory, run vside.enu.exe to launch the actual VS2 2008 Shell installer.

2) Install F# CTP
2a) Download F# September 2008 Release Installer (InstallFSharp.msi)
2b) Run the F# September CTP Installer, the default settings work great.

3) Install VSLab
3a) Download VSLab
3b) Run the VSLab Installer, the default settings work great here too.

4) Install Managed Direct X
4a) Download the latest DirectX End-User Runtimes (August 2008)
4b) Run the installer to extract the DirectX End-User Runtimes to a temporary directory.
4c) Inside that directory, Run DXSETUP.exe to update your DirectX drivers.

You now have a complete VSLab installation.

Quick Start Information

1) First off, launch Visual Studio 2008 to get started.
2) Go to File->New->Project
3) Select Project Type: Visual F# and the VSLab Template
4) Hit Shift+Alt+V To activate the VSLab Interface
5) Right Click on your project and Click Add->New Item
6) On the left select the VSLab Category and Select the a the Viewer3D template.

Select all of the code before the calls to Close() and hit Alt-Enter to execute.

The real version is even animated.

Congratulations, you are now all set up to play with VSLab and F#.

Keys:
Shift+Alt+V: Starts The VSLab Interface
Alt-Enter: Send selected code to the F# interactive tool window

References:
The VSLab Tutorial is a great resource but has not yet been updated for the new VSLab release. Note that the key bindings have changed as mentioned above and keep an eye on the VSLab Blog for updates.

edit: fixed a link and added a picture from VSLab.