Matthew Podwysocki

Introduction to the Reactive Framework Part II

Matthew.Podwysocki — Tue, 03 Nov 2009 05:28:37 GMT

In my previous post, I talked a little bit about the parts of the Reactive Framework that are coming to the .NET 4 BCL as well as their implementation in F# as part of F# First Class Events. This time, let’s come back to the Reactive Framework itself from which the IObservable<T> and IObserver<T> originated. As you may remember, you can play with the bits of the Reactive Framework from the Silverlight 3 Toolkit.

In the first post in the series, I gave a basic introduction to the basic problems we have with asynchronous and reactive programming. We covered some of the evolution of the .NET framework with asynchronous programming and where the Reactive Framework fits. This time, I’ll pick up where we left off to talk about one of the important ideas behind the Reactive Framework, the duality of Enumerable and Observable.

The Duality of Enumerable & Observable

During Erik’s appearances on Channel 9, an important, yet recurring theme was the mathematical duality of the Enumerable to the Observable. What does that mean exactly though?

We remember from our first post in the series where we talked about the pull (interactive) versus the push (reactive) model. The pull model, represented by the iterator pattern of IEnumerable<T>/IEnumerator<T> states that we must explicitly call a method in order to get each item from our abstracted collection. On the other hand, our push model, represented by the observable pattern of IObservable<T>/IObserver<T> states that we register an interest through a subscription and then items are subsequently handed to us from some abstracted collection.

First, let’s look at the iterator pattern, which is a common interactive programming pattern that’s used quite frequently inside .NET. This consists of two interfaces, the IEnumerable<T> and the IEnumerator<T>. Listed below are some of the highlights of these two interfaces. I cut down what they are to their essential bits.

public interface IEnumerable<T>
{
    IEnumerator<T> GetEnumerator();
} 

public interface IEnumerator<T> : IDisposable
{
    T Current { get; }
    bool MoveNext();
}

The IEnumerable<T> interface exposes a single method which returns an IEnumerator<T> to iterate some object. The IEnumerator<T> gives us the ability to get the current item and determine whether there are more items to iterate.

To think about basic asynchronous programming, we must consider a basic Gang of Four Pattern, the Observer Pattern. This pattern describes where an object called an Observable, maintains a list of its dependent Observer classes and notifies them automatically of any state changes. In Java, this should be rather familiar territory with the java.util.Observer class and the java.util.Observable interfaces. In the Reactive Framework, this approach is no different, as we have an IObservable<T> interface which maintains a list of dependent IObserver<T> interfaces and notifies them automatically of any state changes. Let’s look at the signatures below:

public interface IObserver<T>
{
    void OnCompleted();
    void OnError(Exception exception);
    void OnNext(T value);
} 

public interface IObservable<T>
{
    IDisposable Subscribe(IObserver<T> observer);
}

What you may notice, and what you may have seen on some of Erik Meijer’s Channel 9 videos is that there is a duality between the Enumerable and Observable, given the signature of these interfaces. To explain what I mean, let’s first look at the flow of the Enumerator:

The GetEnumerator function takes no arguments and returns the IEnumerator<T> which has a no-argument function and returns the next item in the list through MoveNext and Current. Now, let’s look at the inverse of it.

The duality of the Enumerable solution is quite simple. We have our observer on the left hand side which has an action function which takes a T argument and returns void. The right hand side is the notification that is sent when something happens. This is all managed by the Observable as it maintains a list of all observers so that it can notify them.

To make this a little more concrete, let mash these two sets of interfaces together in order to dualize. First, let’s start with the IEnumerator<T> interface.

public interface IEnumerator<T> : IDisposable
{
    T Current { get; } // throws exception
    bool MoveNext();
}

What we’ll notice is that we have two items the Current property with a get accessor and the MoveNext method which takes nothing and returns a boolean that indicates if it can move next. You’ll also notice that our Current property also could throw an exception. If we’re in the Java world, we’d explicitly mark this interface with throws Exception, but as C# doesn’t have that, this comment will do. Now, let’s look to dualize this interface.

public interface IDualEnumerator<T>
{
    void SetCurrent(T value | Exception ex);
    void MoveNext(bool canMove);
}

At first glance, all we have to do is flip our Current property to have a setter. Because the Current yielded a value or threw an exception, that’s the way we’ll model it for now. Secondly, our MoveNext will now take a boolean to indicate whether we’re done. Let’s refactor this a little bit more and break the SetCurrent into two distinct operations, one for yielding the next value, and one for throwing an exception.

public interface IDualEnumerator<T>
{
    void Yield(T value);
    void Throw(Exception ex);
    void MoveNext(bool canMove);
}

Now that we have that under control, let’s then move onto our MoveNext method. As you’ll notice, we’ll continue to send in a true until we’re finished pushing values. Instead of calling MoveNext repeatedly, let’s instead call this only once when we’re finished.

public interface IDualEnumerator<T>
{
    void Yield(T value);
    void Throw(Exception ex);
    void Break();
}

What we then end up with is pretty much the signature of our IObserver<T>. By renaming our Yield to OnNext, our Throw to OnException and Break to OnCompleted, we’re left with our original IObserver<T> interface.

public interface IObserver<T>
{   
    void OnNext(T value);
    void OnError(Exception exception);
    void OnCompleted();
}

What about the dual of IEnumerable<T>? Let’s first look at what that interface is.

public interface IEnumerable<T>
{
    IEnumerator<T> GetEnumerator();
}

This interface has a single method called GetEnumerator which returns an IEnumerator<T>. How might we dualize this interface? Well, we already know that the dual of the IEnumerator<T> is IObservable<T>, just as well, we need a way to attach interest in a given dualized Enumerator, so we’ll create a method called Attach. Just as well, when we attach interest, we also need a way to detach our interest for a given observer. That might look like the following.

public interface IDualEnumerable<T>
{
    void Attach(IObserver<T> observer);
    void Detach(IObserver<T> observer);
}

If we look at the Java interfaces for Observer and Observable, these are pretty close in signature. There ultimately is a problem with this scenario in terms of composition. At each level, it needs to remember which things maps to which so that you could undo any of the observers if need be. Not doing so could lead to space leaks and is generally a bad idea. How could we solve this then? Ultimately, we need a way to track our attachment once we call the Attach through some form of a return value. At this point, the tracking is nothing more than needing the ability to detach our given Observer. If you’ll notice in our IEnumerator<T> interface, it inherits the IDisposable interface which gets one thinking. Could we instead, change our Attach method so that when we call it, we return an IDisposable instead which gives us the ability to track our subscription and be able to clean up after we’re done? That’s exactly the approach that the IObservable<T> takes in the final version of the interface.

public interface IObservable<T>
{
    IDisposable Subscribe(IObserver<T> observer);
}

Now that we’ve proven the duality, why does it matter? Because of this duality, the laws that apply to LINQ to Objects now can apply to LINQ to Observables (or Events). And in fact, we can see that through the Observable class which has many of our standard LINQ combinators such as:

Aggregate
First/FirstOrDefault
GroupBy
Join
Last/LastOrDefault
Select
SelectMany
Single/SingleOrDefault
Skip/SkipWhile
Take/TakeWhile
Where
Zip

Because of this duality, we can do such simple things as fire the ProgressChanged event until the RunWorkerCompleted event happens.

var worker = new BackgroundWorker();

var percentage = from progress in worker.ProgressChangedEvent()
                           .Until(worker.RunWorkerCompletedEvent())
                 select progress.EventArgs.ProgressPercentage;

var subscription = percentage.Subscribe(
    p => Console.WriteLine("Percentage Complete: {0}", p));

That’s only scratching the surface of the power of the Reactive Framework. We’ll go in depth in the next part of the series on the combinators. We could go into the fact that the Enumerable solution is really just the lazy list monad and the Observable solution is really just the continuation monad, but that’s for another time as well.

Conclusion

As I’ve stated before, the LiveLabs Reactive Framework gives us the ability to harness reactive programming and treat events as the first class citizens they should have been using LINQ expressions and other standard LINQ combinators. Still, there is much to cover in this series with the standard LINQ combinators, the monadic heritage of this solution and more.

F# October 2009 CTP/Beta2 – F# + Rx Together At Last

Matthew.Podwysocki — Mon, 19 Oct 2009 22:37:24 GMT

Lately, I’ve been covering a lot of F# First Class Events as well as the Reactive Framework which has been leading up to a head as it were. It has been announced through Channel 9 that .NET 4 will include the two major interfaces from the Reactive Framework, the IObservable<T> and IObserver<T>. Today, as Don Syme announces with the release of the F# October 2009 CTP and F# for Visual Studio 2010 Beta 2, those two interfaces, the IObservable<T> and IObserver<T> have been integrated into F# First Class Events.

What does that mean and what are the implications?

Mixing in Observables

In the previous version of F#, you may remember that we dealt primary with the IEvent interface and if you needed the ability to subscribe and unsubscribe, you would use the IDelegateEvent interface. Let’s look at how this was implemented in the past.

type IDelegateEvent<'Delegate when 'Delegate :> System.Delegate > =
  abstract AddHandler: handler:'Delegate -> unit
  abstract RemoveHandler: handler:'Delegate -> unit 

type IEvent<'Delegate,'Args when 'Delegate : delegate<'Args,unit> and 
                                 'Delegate :> System.Delegate > =
  abstract Add: callback:('Args -> unit) -> unit
  inherit IDelegateEvent<'Delegate>

As you’ll note, we had the ability to add and remove delegate handlers using the AddHandler and RemoveHandler methods with our IDelegateEvent interface and our ability to add a handler via the Add method in the IEvent interface. Both of these gave us some pretty rich options when dealing with first class events. When the Reactive Framework interfaces were to be folded in to .NET 4.0, it was only a matter of time before the F# team looked on how to integrate the idea of Observables and F# First Class Events. WIthin the Visual Studio 2010 Beta 2 download, you’ll find that F# does in fact reference the System.IObservable<T> and System.IObserver<T> interfaces. If you are still using Visual Studio 2008, these interfaces have also been included as well so that you can take advantage of them. Now if we are to look at how F# First Class Events work now, let’s go over the inheritance chain.

type IObserver<'T> =
  abstract OnNext : value : 'T -> unit
  abstract OnError : error : exn -> unit
  abstract OnCompleted : unit -> unit

type IObservable<'T> =
  abstract Subscribe : observer : IObserver<'T> -> System.IDisposable
  
type IDelegateEvent<'Delegate when 'Delegate :> System.Delegate > =
  abstract AddHandler: handler:'Delegate -> unit
  abstract RemoveHandler: handler:'Delegate -> unit 

type IEvent<'Delegate,'Args when 'Delegate : delegate<'Args,unit> and 
                                 'Delegate :> System.Delegate > =
  inherit IDelegateEvent<'Delegate>
  inherit IObservable<'Args>

What you’ll now notice is that we have in code, defined our IObserver<T> and IObservable<T> which either come from the .NET 4.0 base class library or in F# itself for Visual Studio 2008, and then we have our IEvent<TDel,T> inheriting both the IDelegateEvent<TDel> and the IObservable<T> interfaces. This means that when we’re dealing with First Class Events in F#, we can go back and forth from using the IEvent<TDel,T> and IObservable<T> interfaces, based upon our needs. So, what does that buy us?

Exploring Observables

Much like the Event module in F# defines combinators for F# First Class Events, the Observable module defines the standard combinators for using the IObservable<T> interface. Much like the Event module, the Observable module includes add, filter, map, partition, merge, choose, and scan. Let’s go over these briefly about what each one is about.

add
Create an observer which permanently subscribes to the given observable and which calls the given function for each observation.
subscribe
Create an observer which subscribes to the given observable and which calls the given function for each observation.
map
Return an observable which transforms the observations of the source by the given function. The transformation function is executed once for each subscribed observer. The returned object also propagates error observations arising from the source and completes when the source completes.
filter
Return an observable which filters the observations of the source by the given function. The observable will see only those observations for which the predicate returns true. The predicate is executed once for each subscribed observer. The returned object also propagates error observations arising from the source and completes when the source completes.
scan
Return an observables which, for each observer, allocates an item of state and applies the given accumulating function to successive values arising from the input. The returned object will trigger observations for each computed state value, excluding the initial value. The returned object propagates all errors arising from the source and completes when the source completes.
choose
Return an observable which chooses a projection of observations from the source using the given function. The returned object will trigger observations x for which the splitter returns Some x. The returned object also propagates all errors arising from the source and completes when the source completes.
partition
Return two observables which partition the observations of the source by the given function. The first will trigger observations for those values for which the predicate returns true. The second will trigger observations for those values where the predicate returns false. The predicate is executed once for each subscribed observer. Both also propagate all error observations arising from the source and each completes when the source completes.
split
Return two observables which split the observations of the source by the given function. The first will trigger observations x for which the splitter returns Choice1Of2 x. The second will trigger observations y for which the splitter returns Choice2Of2 y. The splitter is executed once for each subscribed observer. Both also propagate error observations arising from the source and each completes when the source completes.
merge

Return an observable for the merged observations from the sources. The returned object propagates success and error values arising from either source and completes when both the sources have completed.

You’ll notice one difference from the Event module to the Observable module is the inclusion of the subscribe function. This allows us to subscribe to an observable, which in turn will return an IDisposable. This IDisposable, as I’ve covered before, allows us to nicely tell the system when we’re no longer interested in receiving notifications instead of having to tell the observer when we want to attach and detach. We’ll cover more of this in a future post on the Introduction to the Reactive Framework series.

What does this change buy us exactly? Well, now we can treat observables much the same as we would for F# first class events. Now we can take an example from a previous post and show how we can create two observables based upon whether the X and Y coordinate of the mouse is in a certain location as we drag it across our form.

// Create form
let form = new Form(Visible=true, TopMost=true, Text="Event Sample")

// Create under and over for X and Y coordinates
let (overEvent, underEvent) =
  form.MouseDown
  |> Observable.merge form.MouseMove
  |> Observable.filter (fun args -> args.Button = MouseButtons.Left)
  |> Observable.map (fun args -> (args.X, args.Y))
  |> Observable.partition (fun (x, y) -> x > 100 && y > 100)

// Subscribe to each
let overSubscription =
  overEvent 
  |> Observable.subscribe (fun (x, y) -> printfn "Over (%d, %d)" x y)
let underSubscription =
  underEvent 
  |> Observable.subscribe (fun (x, y) -> printfn "Under (%d, %d)" x y)
  
// Much later, clean up
overSubscription.Dispose()
underSubscription.Dispose()

As you can see from this code, we’re treating our Observables no differently than we would our F# First Class Events. With the inheritance chain of the IEvent from the IObservable, we get seamless integration between the two. Unlike C#, we don’t need to create extension methods to turn our events into observables and instead get that for free.

Conclusion

What you will notice is that we lack many of the combinators that the Reactive Framework has built in such as Until/WaitUntil, Take/TakeWhile, Skip/SkipWhile among others for which we’ll cover in the Introduction to the Reactive Framework series. Many of these aren’t hard to implement and we’ll get the added benefit of exception management that the Observables give us.

It’s pretty interesting to see how F# has evolved from release to release. This release for Visual Studio 2010 Beta 2 and the F# October 2009 CTP have some nice changes as noted in the release notes. The integration of the IObservable/IObserver is not to be overlooked as one of them. Download them today and give the team feedback! Now back to our Observables series.

[ANN] DC ALT.NET 10/22/2009 – MongoDB with David James

Matthew.Podwysocki — Fri, 16 Oct 2009 03:38:45 GMT

This month DC ALT.NET will once again move into the not often covered subjects in the .NET world, in covering MongoDB with David James. Stay tuned to the mailing list for up to date details. There has been a bit of discussion around non relational databases lumped under the name of NoSQL, especially given the upcoming NoSQLEast conference. This meeting, we'll dive into MongoDB, one of the NoSQL solutions.

MongoDB is an open source document-oriented database written in the C++ programming language. Like other document-oriented databases, MongoDB is designed for problems without heavy transactional requirements that aren't easily solved by traditional relational databases, including problems which require the database to span many servers. K. Scott Allen has a great writeup on how to use MongoDB from C# that you can find here and is a great read. And yes, there is even LINQ support as well. Come join us and find out what NoSQL alternatives can do for you.

Also, we'll have a hacking session for those interested, so be sure to install MongoDB beforehand. The presentation will be mainly in Ruby and JavaScript, but there are C# options available as well.

About David James

David James is a Web Developer for Sunlight Labs. Prior to joining Sunlight, David founded CommunityGoals, a socially minded startup, and Collective Insight, a technology consultancy. He has worn the hats of entrepreneur, analyst, software developer, and consultant while working in fields including software, energy, and hardware engineering. David has a Master of Public Affairs degree from the LBJ School of Public Affairs, a liberal arts BA degree and an electrical and computer engineering BS degree from The University of Texas at Austin. He enjoys building tools that advance causes such as open government, community development, and environmental and energy policy. David also enjoys playing the piano and cycling and is sometimes known for coaxing friends into sprinting for city limit signs.

Date/Time: 10/22/2009 – 7-9PM

Location:
The Motley Fool
2000 Duke Street
Alexandria, VA 22314

F# First Class Events – Composing Events Until Others

Matthew.Podwysocki — Thu, 15 Oct 2009 05:43:52 GMT

After a comment on my last post in regards to First Class Events in F#, I thought I’d revisit them briefly before going back to the Reactive Framework series. In particular, this comment was in regards to implementing the until combinator using F# First Class Events. As part of my hacking during this series, I came across a rather identical solution to the one that was posted, so I thought it’d be worth exploring.

Implementing Until

The idea behind the until event combinator is to that we will return values from our event until any notification from the other event occurs. In order to accomplish this, we must subscribe to the other event and if it has fired, then we reset a flag to not fire. We then have to subscribe to the main event and only trigger when the flag is set to true. Let’s look through how this code might look.

module Event =

 let until (other: IEvent<_,_>) (source: IEvent<_,_>) =
   let event = new Event<_>()
   let fire = ref true
   other .Add(fun _    -> fire := false)
   source.Add(fun args -> if !fire then event.Trigger args)
   event.Publish

In order for us to modify the fire flag, we must use a ref cell. The reason being is that local mutables are always stack allocated which is why you cannot capture them inside a closure. One comment that was made about this solution was that we added two subscriptions for creating this single event. That indeed can be a problem as Tess Ferrandez points out about event handlers that made the memory balloon where you hook up to static event handlers that long outlive pages. That’s not necessarily something we’ll address here, and it’s rare that we’ll run into this situation.

Now that we have this until defined, what can we do with it? In my previous post, we used the WebClient to track the progress changed of a download until the download has completed. We’ll use that same logic here using our F# first class events.

open System
open System.Net

type IDelegateEvent<'Del when 'Del :> Delegate > with
  member this.Subscribe(d) =
    this.AddHandler(d)
    { new IDisposable with
        member disp.Dispose() =
          this.RemoveHandler(d) }

let wc = new WebClient(Credentials = new NetworkCredential("foo","bar"))

let progSub =
  wc.DownloadProgressChanged
  |> Event.until wc.DownloadStringCompleted
  |> fun event -> 
       event.Subscribe(fun _ args -> printfn "%d%% Complete" args.ProgressPercentage)

let downloadSub =
  wc.DownloadStringCompleted.Subscribe (fun _ args -> printfn "%s" args.Result)

Here, once again I’m using the extension method I created that allows us to dispose of our event handlers easily through an IDisposable interface. This follows the design of the Reactive Framework, and quite frankly, makes a lot of sense. What we’re able to do is create our DownloadProgressChanged subscription which listens until the DownloadStringCompleted event and then we output our percentage complete as it goes along. The download subscription is much like before in that we subscribe to the event and can dispose at any time later in our program.

Adding Some Monadic Magic

Let’s add another wrinkle here to our solution. What if we want to create our mouse drag event like we had from the previous post using the Reactive Framework? Let’s review the code that was required in Rx to make this happen.

var mouseDrag = from md in this.GetMouseDown()
                from mm in this.GetMouseMove().Until(this.GetMouseUp())
                select mm;

I may have hinted in the previous post, that LINQ to Objects is an implementation of the list monad and the Reactive Framework is an implementation of the continuation monad. As Erik points out in one of his recent Channel 9 episodes, indeed many of the interesting things we’re finding in programming are coming in monadic form. We’ll cover exactly what that means in a later post, but what if we could apply the same kind of logic from the above and apply it to F# first class events as well?

In order to make this happen, we need to implement a bind/collect combinator. This bind function follows the basic pattern of:

val bind : M<'a> -> ('a -> M<'b>) -> M<'b>

Where the M is some monadic type. In the case of LINQ to Objects, this is the SelectMany method and the M type is an IEnumerable<T>. If we were to construct the collect combinator from scratch for an IEnumerable<T>, it might look like the following:

let collect f = Seq.map f >> Seq.concat

And our approach to doing this with events should be no different. In this case, we also need to implement the concat combinator as well as that does not exist in the base libraries but pretty simple to create. First, with the concat, we need to take in a IEvent of an IEvent and concatenate them together in a way that we get only an IEvent as a return. In order to do so, we need to add a handle to our source, which in turn listens to the inner events and triggers our new event that we later publish. Secondly, we’ll need to implement the collect combinator much like we had above, but this time for events. Below is what the code might look like.

module Event =

 let concat (source: IEvent<IEvent<_,_>>) =
   let event = new Event<_>()
   source.Add (Event.listen event.Trigger)
   event.Publish

 let collect f =
   Event.map f >> concat

Now that we have a basis for binding together our events, let’s create a monadic builder so that we could write event expressions much as we would for sequence expressions. In this case, we only need the bind and not the return for this instance. A simple return wouldn’t make sense to yield a single value through an event.

type EventBuilder() =
  member this.Bind(m, f) = Event.collect f m
let event = new EventBuilder()

Now that we have this defined, F# gives us some syntactic sugar much like the do notation in Haskell. Let’s now add an extension method to the WinForms Control class.

type System.Windows.Forms.Control with
  member this.MouseDrag = event {
    let! _ = this.MouseDown
    return! this.MouseMove |> Event.until this.MouseUp }

And there you have it! We now have a mouse drag event exposed on our control class which tracks only when the mouse button is down and our mouse is moving. To get an idea of what it’s doing behind the scenes, I’ll also include the non-syntactic sugar version.

type System.Windows.Forms.Control with
  member this.MouseDrag = 
    event.Bind(this.MouseDown, fun _ ->
      this.MouseMove |> Event.until this.MouseUp)

And now we can subscribe to this much like any other event and have it track our mouse.

Conclusion

Creating composable events using F# first class events is a pretty compelling story. One of the driving ideas behind the Reactive Framework in terms of composable events does in fact come from F#. Come .NET 4.0, it will be interesting on how Rx and F# First Class Events can co-exist and in fact compliment each other. Now back to the Reactive Framework series.

Introducing the Reactive Framework Part I

Matthew.Podwysocki — Wed, 14 Oct 2009 05:21:45 GMT

During my series about first class events in F#, I made frequent mention of the LiveLabs Reactive Framework (Rx), without going into much detail as to what it is. Now that the series is complete and we understand both how F# first class events work, as well as their integration into F# async workflows, let’s take a look at the Reactive Framework in this multi-part series covering the history, implementation details and more.

You may already be familiar with the Reactive Framework due to the videos that Erik Meijer, Wes Dyer and Charles Torre have put on Channel 9. Each of the following are well worth a watch:

What and Why?

So, the question of what are the motivations of Rx? The first question to ask yourself is “How easy is it in today’s frameworks to do asynchronous programming?” The answer usually that it’s actually quite difficult, to not only manage exceptional cases and cancellation, but also, how do you compose asynchronous events together to create more interesting events? The need is actually quite great especially given our multi-core revolution. So, how can we take advantage to do some rich, reactive programming like AJAX-style applications?

After covering some of my posts on F# async workflows and F# first class events, some of those motivations start to appear, such as how do you make asynchronous programming and reactive programming truly composable? Let’s look at the standard ways of doing asynchronous programming currently on the .NET platform. In the past, we’ve had to write things such as this in order to asynchronously read data from a Twitter feed:

var request = WebRequest.Create("http://twitter.com/statuses/friends_timeline.xml");
request.Credentials = new NetworkCredential("foo", "bar");
request.BeginGetResponse(ar =>
{
    using(var response = request.EndGetResponse(ar))
    using(var stream = response.GetResponseStream())
    using (var reader = new StreamReader(stream))
        PublishResult(reader.ReadToEnd()); // Do something with the result
}, null);

Since the beginning of .NET, we had both events and the Begin/End with an IAsyncResult for doing asynchronous programming, the latter of which we’ve shown above. The problem with both is that they weren’t easy to handle exceptions and cancellation. By the time .NET 2.0 came around, there was a new approach to doing asynchronous programming that in fact handled such concerns. Such classes as the BackgroundWorker, WebClient and WCF service clients followed this approach. For example, we could download a user’s timeline from Twitter using the WebClient class.

var wc = new WebClient 
    {Credentials = new NetworkCredential("foo", "bar")};
wc.DownloadStringCompleted += (o, e) =>
{
    if(e.Cancelled)
    {
        PublishCancel();
        return; // Handle cancellation
    }
    if(e.Error != null)
    {
        PublishException(e.Error);
        return; // Handle error
    }

    PublishResult(e.Result); // Handle success
};

As you can see, we can somewhat elegantly handle not only the result, but the cancellation and exceptional cases as well. The problem of course is that there is really no way to unsubscribe from this lambda expression, and just as well, the solution really isn’t composable. How could I merge this event with another event, or say stop listening after a certain interval or another event happens? Unlike in F#, in C#, we have no real easy way to deal with a lot of these situations. Not only that, but we could leave dangling events out there which could be a nice memory leak.

So, how could this Rx thing help? Let’s look at a quick example of how it’s different before we go into detail about what it is. In this example, I’ll build upon it to succinctly handle the exceptional case, but not only that, but also watch the progress changed until the download has completed.

var wc = new WebClient 
    { Credentials = new NetworkCredential("foo", "bar") };
    
// Watch progress only until download complete
var progress = wc.DownloadProgressChangedEvent()
    .Until(wc.DownloadStringCompletedEvent());

// Subscribe which creates IDisposable handlers
// Handle success and exceptional cases

var progressHandler = progress.Subscribe(
    e => PublishProgress(e.EventArgs.ProgressPercentage));
    
var downloadHandler = wc.DownloadStringCompletedEvent().Subscribe(
    e => PublishResults(e.EventArgs.Result),
    exception => PublishException(exception));

...

// Much later in the program, we can dispose
progressHandler.Dispose();
downloadHandler.Dispose();

What we did was allow us to handle exceptional cases as well as the success case on the next invocation of the observable. I create extension methods which I will cover later, but I want you to get the gist of how this might work. Since we’re only interested in one firing, we can dispose of the progress subscription quite easily since any call to Subscribe returns an IDisposable which allows us to unsubscribe from our event easily. This is a similar approach in my F# event posts which allowed me to unsubscribe from any event when I call the subscribe extension method I created.

To give one more example about composability, how about creating a simple mouse drag event? How might we do that given the current state of eventing in .NET?

public event MouseEventHandler MouseDrag;

private void InitializeMouseDrag()
{
    MouseDrag += (o, e) => PublishMouseDrag(o, e);

    var fired = false;
    MouseDown += delegate { fired = true; };
    MouseUp += delegate { fired = false; };
    MouseMove += (o, e) =>
    {
        if (fired && MouseDrag != null)
            MouseDrag(this, e);
    };
}

What we’re doing is determining whether our mouse down and mouse move are firing together and if they are, publish the coordinate to the MouseDrag event. From this code, it’s rather clumsy in order to do this. Luckily, the Reactive Framework gives us a better alternative for handling such a thing.

// Create mouse drag
var mouseDrag = from md in this.GetMouseDown()
                from mm in this.GetMouseMove().Until(this.GetMouseUp())
                select mm;

// Subscribe
var handler = mouseDrag.Subscribe(
    e => PublishMouseDrag(e.EventArgs.Location));

...

// Clean up when we're done with the event
handler.Dispose();

When creating this mouse drag observable, I am able to use LINQ expressions to compose my Observables create from extension methods in order to track mouse down and mouse move until mouse up. Now are we starting to see the power here?

Now that we got a feel of what it might look like, what is it?

The Reactive Framework

There has been a lot of talk around the Reactive Framework on both Channel 9 and among the blogs. Since the Reactive Framework has been shipped as part of Silverlight 3 Toolkit, there has been a bit of interest. Just as LINQ to objects changed the way we thought about interactive programming, the Reactive Framework will change the way we think about reactive programming.

Let’s first cover some basic terms here with interactive and reactive programming. When we talk about interactive programming, we’re talking about asking for something and getting it in return. One common pattern in this world is the iterator pattern. In contrast, when we think about reactive programming, we register interest and then we have items handed to us asynchronously as they become available. To give a sushi bar analogy, you could think of interactive programming as the conveyer and as it moves we pick another piece of sushi from the line and put it on our plate. In contrast, with reactive programming, we register interest that we want sushi, and as they become available, the chef hands us them asynchronously.

To put this in code terms, let’s show the interactive version of our sushi model. We have several items that we wish to eat, but we will only have them delivered if we ask for them.

static IEnumerable<string> GetSushi()
{
    yield return "Toro";
    yield return "Maki";
    yield return "Uni";
}

// Pull each sushi piece from the conveyor
foreach(var piece in GetSushi())
    ConsumeSushi(piece);

Inside the IEnumerable<T>, we have our items waiting to go, but will only move when we ask for them. The inverse would be where we indicate we’re hungry by subscribing to the observable which contains our sushi. At that point, the house gives us sushi when they are ready and we don’t have to ask for each piece, instead they are pushed to us.

// Build up our menu
static IObservable<string> GetSushi()
{
    return Observable.Cons("Toro", 
        Observable.Cons("Maki", 
        Observable.Return("Uni")));
}

// Eat them as soon as they come to us
var sushiSubscription = GetSushi().Subscribe(
    piece => ConsumeSushi(piece));

In the above example, I built up our observable menu of sushi using the Cons and Return static methods on the Observable class. Then at the bottom, I subscribe that I want to eat them, so I call subscribe passing in my action which fires on each item in our observable.

The reason I focus on this, is that there is a certain duality to push and pull, and especially given the way they were designed. In our above example, the Iterator pattern is a common interactive programming pattern that’s used quite frequently inside .NET. This consists of two interfaces, the IEnumerable<T> and the IEnumerator<T>. Listed below are some of the highlights of these two interfaces. I cut down what they are to their essential bits.

public interface IEnumerable<T>
{
    IEnumerator<T> GetEnumerator();
}

public interface IEnumerator<T> : IDisposable
{
    T Current { get; }
    bool MoveNext();
}

To think about basic asynchronous programming which we’re doing with our observables, we must consider a basic Gang of Four Pattern, the Observer Pattern. This pattern describes where an object called an Observable, maintains a list of its dependent Observer classes and notifies them automatically of any state changes. In Java, this should be rather familiar territory with the java.util.Observer class and the java.util.Observable interfaces. In the Reactive Framework, this approach is no different, as we have an IObservable<T> interface which maintains a list of dependent IObserver<T> interfaces and notifies them automatically of any state changes. Let’s look at the signatures below:

public interface IObserver<T>
{
    void OnCompleted();
    void OnError(Exception exception);
    void OnNext(T value);
}

public interface IObservable<T>
{
    IDisposable Subscribe(IObserver<T> observer);
}

What we also get is much like the System.Linq.Enumerable class contains many extension methods for handling IEnumerable<T>, we have the System.Linq.Observable class which contains many of those same extension methods for IObservable<T> instances. We’ll go into depth of what they are later in this series.

What you may notice, and what you may have seen on some of Erik Meijer’s Channel 9 videos is that there is a mathematical duality between the Enumerable and Observable, given the signature of these interfaces, as well as the ideas between push and pull. I’ll go into exactly what that means in the next post.

Conclusion

SImply stated, asynchronous programming is hard. To not only manage exceptions and cancellation, but also to make events composable is yet another challenge. The LiveLabs Reactive Framework gives us the ability to harness reactive programming and treat events as the first class citizens they should have been using LINQ expressions and other standard LINQ combinators. There is a lot to cover including the mathematical duality, what it is underneath the covers and so on.

Functional Programming Fundamentals Lectures

Matthew.Podwysocki — Fri, 09 Oct 2009 04:38:39 GMT

Earlier this year, I had the privilege to record a Channel 9 video session covering functional programming basics with Erik Meijer and Charles Torre. We covered some of the basics, but at some point you need to go back to the fundamentals in order to truly learn this paradigm. With that, Erik with the help of Charles, have kicked off the Channel 9 lecture series on Functional Programming Fundamentals. This series is meant to be a journey into some of the ideas behind functional programming, following along with Graham Hutton’s excellent Programming in Haskell book. Many of the concepts described in this series are in Haskell first, but many apply as well to F#, and even C# and VB.NET. What better way to talk about Haskell and functional programming than to learn from one of the authors of the Haskell 98 Report. I highly encourage everyone to check out this series!

You can find the links for the Channel 9 Lecture Series to see all the videos.

Generically Constraining F# – Part III

Matthew.Podwysocki — Fri, 02 Oct 2009 05:14:47 GMT

In the previous post, we talked about some of the generic restrictions that you could do in F#. I showed some of the basics and how you might use them to your advantage. We covered the type constraint, null constraint and explicit member constraint. This time, we’ll cover the rest of them including:

Constructor constraint
Reference type constraint
Enumeration type constraint
Delegate type constraint

Constructor contstraint

The constructor constraint in F# is identical to that of C# which states that the specified type must have a default constructor. In order to use this, we must use the <type> : (new : unit –> <type>). Let’s walk through a basic example of using this in addition to the type constraint to generate a hash of a given file.

open System
open System.Security.Cryptography

let generateHash<'a when 'a : ( new : unit -> 'a)
                    and  'a :> HashAlgorithm>
 path =
  let algo = new 'a()
  use stream = File.OpenRead path  
  algo.ComputeHash stream
  |> BitConverter.ToString
  |> fun s -> s.Replace("-","")

What this code does is first declares that our type must have a default constructor and must derive from System.Security.Cryptography.HashAlgorithm. We can create our new generic type much as we would in other languages that support such a feature and then use it to generate our hash. Let’s verify the behavior by generating an MD5 hash of notepad.exe using the Cryptography Next Generation MD5 class.

> generateHash<MD5Cng> "notepad.exe";;
val it : string = "D3002BDDC758A762736730DE399920E5"

Reference Type Constraint

Much like the constructor constraint, this constraint is also identical to the C# class constraint. In C#, this restraint is rather oddly named, however, due to the fact that it restricts not only classes, but also interfaces, arrays and delegates. Instead, F# chose the more apt name of not struct. Let’s look through an example of using this to initialize a reference type sequence.

let createRefSeq<'a when 'a : not struct> : 'a -> 'a seq =
  Seq.singleton

Now we can verify the behavior of this such as the following:

> createRefSeq "foo";;
val it : seq<string> = seq ["foo"]
> createRefSeq (Func<_>(fun () -> DateTime.Now));;
val it : seq<Func<DateTime>> =
  seq [System.Func`1[System.DateTime] {Method = System.DateTime Invoke();
                                       Target = FSI_0061+it@90-4;}]
> createRefSeq 3;;

  createRefSeq 3;;
  --------------^

stdin(92,15): error FS0001: A generic construct requires that the type 'int'
have reference semantics, but it does not, i.e. it is a struct

Enumeration Constraint

This type constraint, unlike the other two covered in this post cannot be expressed in the current C# version. We covered this constraint as part of how we could solve Jon Skeet’s problem of Enum.GetValues. Let’s revisit that solution with a twist of getting the name from a value.

open System

let getEnumName<'a,'b when 'a :> Enum 
                       and 'a :> ValueType
                       and 'a : enum<'b>>
 (value:'a) =
  Enum.GetName(typeof<'a>, value)

And now we can test our behavior such as the following:

> getEnumName DayOfWeek.Saturday;;
val it : string = "Saturday"

Delegate Constraint

Lastly, the delegate constraint constrains the generic type to be a delegate. This constraint, probably the least used of the constraints, can in fact be put to good use. In order to use this, we must use the <type> : delegate<args, unit> to declare this restriction. In my F# First Class Events series, I covered this as a way of adding subscribe capability to F# events in which we can easily subscribe and unsubscribe from an event based upon handing back an IDisposable which on called, removes the event handler. Let’s go through that solution again.

open System

type IEvent<'Del,'Args when 'Del : delegate<'Args,unit> 
                       and  'Del :> Delegate > with
  member this.Subscribe(d) =
    this.AddHandler(d)
    { new IDisposable with
        member x.Dispose() =
          this.RemoveHandler(d) }

What this allows us to do is add a subscription that we can unsubscribe from easily via the IDisposable object we hand back. Let’s test this a subscription to a Windows Form Click event and then unsubscribe:

> open System.Windows.Forms
- let f = new Form(Visible=true, TopMost=true)
- let count = ref 0
- let h = f.Click.Subscribe(fun _ _ -> count := !count + 1; printfn "%d" !count);;

val h : IDisposable

1
2
3
4
5
> h.Dispose();;

What we did was create a quick form and then add our handler. After a few clicks, we get bored, and then decide to dispose of our little counter. This idea is in keeping with the Reactive Framework which I’ll start on in my next series.

Conclusion

As you can see, the F# language gives us quite a bit of flexibility with generic restrictions. Going above and beyond what C# already has, we are able to constrain to such things as enum, method signatures, delegates and so on. Many of these explicit type signatures, although nice to specify, can be inferred by the F# compiler a lot of the time. With the last segment of first class events, we’ll next step into the Reactive Framework.

Generically Constraining F# – Part II

Matthew.Podwysocki — Mon, 28 Sep 2009 02:32:33 GMT

In the previous post, we talked about the basic problems with C# generic restrictions. We covered how it was possible in fact in the CLR to do these restrictions and sure enough the F# language supports them. This time, we’ll go deeper into what kinds of generic restrictions are possible and how we might use them. But, before we begin, let’s revisit our previous example.

Revisiting Our Previous Example

One commenter correctly pointed out that a more literal translation of the Enum.GetValues would in fact export to C#:

open System
let getValues<'a when 'a : struct and 'a :> Enum>() =
  Enum.GetValues(typeof<'a>) :?> 'a array

In this case, we are using a value type and then a type constraint to ensure that it is both a structure and derives from System.Enum. Alternatively, we could also use the F# enum constraint as well, such as the following:

let getValues<'a,'b when 'a : struct and 'a : enum<'b> and 'a :> Enum>() =
  Enum.GetValues(typeof<'a>) :?> 'a array

And then we could execute as before:

> open System.IO;;
> getValues<FileAttributes, int>();;
val it : FileAttributes array =
  [|ReadOnly; Hidden; System; Directory; Archive; Device; Normal; Temporary;
    SparseFile; ReparsePoint; Compressed; Offline; NotContentIndexed;
    Encrypted|]

Both of these examples work when exported to C# as well. Now that we’re certain we can get C# to respect our generic restriction, what else could we do?

Generic Restrictions

The F# language supports quite a few ways that we can constrain generics. Each one listed below will be gone into detail:

Type constraint
Null constraint
Explicit member constraint
Constructor constraint
Reference type constraint
Enumeration type constraint
Delegate constraint

Type Constraint

A type constraint is where the provided type must be the same or derived from the specified type. In the case of interfaces, the provided type must implement said interface. As you saw earlier in the getValues example, we used a type constraint to ensure that our provided type must derive from System.Enum, as all enums do. In this case, let’s define how to add a line as a child to a given element which implements the IAddChild interface in WPF:

let drawLine<'a when 'a :> IAddChild> stroke (x1, y1) (x2, y2) (e : 'a) =
  let line =
    new LineGeometry(StartPoint = Point(x1, y1), EndPoint = Point(x2, y2))
  let path =
    new Path(Stroke = stroke, StrokeThickness = 5., Data = line)
  e.AddChild(path)

By using the :> operator, we constrain our ‘a type that it must implement the IAddChild interface. Alternatively, we could use the #<type> inline to our parameter to mean the same thing, where type means the what the type must inherit from or implement.:

let drawLine stroke (x1, y1) (x2, y2) (e : #IAddChild) =
  let line =
    new LineGeometry(StartPoint = Point(x1, y1), EndPoint = Point(x2, y2))
  let path =
    new Path(Stroke = stroke, StrokeThickness = 5., Data = line)
  e.AddChild(path)

Null Constraint

In this constraint, the provided type must support being set to null. This will include all .NET reference types, but excludes value types as well as F# types of lists, tuples, functions, classes, records or union types. By using the ‘a : null syntax, we can say that ‘a is a nullable reference. Note that this doesn’t work for Nullable<T> types either. Let’s look at a quick example of using the null constraint:

let printValue<'a when 'a : null> (arg:'a) =
  if arg = null then
    printfn "You gave me nothing"
  else
    printfn "Value: %A" arg

Then we could test the behavior by giving it several examples such as the following:

> printValue "hello";;
Value: "hello"
val it : unit = ()
> printValue null;;
You gave me nothing

Explicit Member Constraint

The explicit member constraint states that the type argument provided must have a member that has the specified signature. This means that we could in fact do duck typing in such a way that our argument must support a certain member function. I’ve covered this in the past, but let’s review. One example would be to create a function which allows us to invoke implicit operators, which are by default not supported by F#.

let inline implicit< ^a, ^b when ^a : (static member op_Implicit : ^b ->  ^a)> 
  arg =
    (^a : (static member op_Implicit : ^b -> ^a) arg)

This allows me to specify that my ^a type must support a static method called op_Implicit, simply known as the implicit operator. Alternatively, we can allow type inference to do the work for us and leave off the top level declaration and declare the function calls inline and the results will be the same.

let inline implicit arg =
  (^a : (static member op_Implicit : ^b -> ^a) arg)

We can test the behavior of this by using the implicit operator built into LINQ to XML. Using the library is not exactly as easy as it is in C# due to the implicit operator from string to XName. In this instance, I’ll use the ( !! ) operator, or the convert dammit operator, to use on the XNamespace class and then append a string to create an XName.

> open System.Xml.Linq;;
> let ( !! ) : string -> XNamespace = implicit;;

val ( !! ) : (string -> XNamespace)

> let foo = !!"" + "foo";;

val foo : XName = foo

As you can see, we created the foo XName by creating an empty XNamespace and appending our “foo”. Before we wrap up this section, let’s try one more example which supports multiple multiple methods. In this case, we’ll extract both the name as an XName, and the value from a given LINQ to XML object. The reason I do this is that the XElement and XAttribute do not share a common ancestor which supports a Name and Value property.

open System.Xml.Linq

let inline getNameValue< ^a when ^a : (member get_Name  : unit -> XName ) and
                                 ^a : (member get_Value : unit -> string)>
 xItem = 
  let name =  (^a : (member get_Name  : unit -> XName ) xItem)
  let value = (^a : (member get_Value : unit -> string) xItem)
  name, value

In this case, we constrain our generic that it must implement both a Name and Value property getter. Then we invoke both the name and value functions and return them as a tuple. Once again, as with above, we can leave off these constraints and let the type inference magic do the work for us.

open System.Xml.Linq

let inline getNameValue xItem = 
  let name =  (^a : (member get_Name  : unit -> XName ) xItem)
  let value = (^a : (member get_Value : unit -> string) xItem)
  name, value

You can begin to see the power in this where we are no longer constrained by inheritance, and instead which methods our type supports. This is different of course than the dynamic type forthcoming in .NET 4.0 as this is statically checked at compile time instead of at runtime. Let’s walk through some simple examples using it:

> getNameValue (new XElement(!!"" + "bar", "foo"));;
val it : XName * string = (bar {LocalName = "bar";
                                Namespace = ;
                                NamespaceName = "";}, "foo")
> getNameValue (new XAttribute(!!"" + "foo", "bar"));;
val it : XName * string = (foo {LocalName = "foo";
                                Namespace = ;
                                NamespaceName = "";}, "bar")
> getNameValue (new XDocument());;

  getNameValue (new XDocument());;
  --------------^^^^^^^^^^^^^^^

stdin(238,15): error FS0001: The type 'XDocument' does not support any operators
 named 'get_Name'

Now you can see it works nicely with XElement and XAttribute, but not with XDocument as it doesn’t support the Name property with a getter accessor, nor does it support a Value property either. I think that’s enough for this post.

Conclusion

So far, we’ve covered just a few of the generic type constraints that you can do with F# including type, null constraint and member constraint. In the next part, we’ll cover the rest of the generic constraints that F# supports.

Pondering Axum + F#

Matthew.Podwysocki — Fri, 25 Sep 2009 19:42:05 GMT

It’s been a while since I’ve posted about Axum as I’ve been posting about other asynchronous and parallel programming models. After two releases of the Axum standalone language and lots of good user feedback, it’s time to ponder what could be with Axum. Overall, the goals of Axum to provide an agent-based concurrency oriented system is important as we consider the emerging hardware trends. Many of these ideas would in fact benefit most languages, whether mainstream or not. With all the success that it has had, there have also been some issues as well, which leads me to wonder, what else could we do here? Let step through some of those issues today and see where we could go.

Should It Be Its Own Language?

One of the highlighted concerns was the need to have yet another language. Creating and maintaining languages is a large effort, not to be undertaken lightly at any organization. To base your language on C# while adding additional constructs was a great way to get started and create some buzz and buy-in, but it also brought its own set of problems.

One problem is that it is an enormous effort to keep on par with the C# compiler and add these constructs on a continuing basis. The Spec# project, also based upon C# realized that it wasn’t feasible to keep up with the rapid pace of the language and instead went as a language neutral approach. Not only keeping up with the language, but to enforce many functional programming constructs that Axum embraces such as immutability and purity are harder to enforce given a language which is built upon object-oriented and imperative approaches, an approach which encourage the encapsulation and manipulation of state. So, instead of creating a separate language, why not fold these constructs into an existing language instead?

The Case For F#

Given the impedance mismatch between the C# language and the overall goals of Axum for a safe, isolated, agent-based system that is great for concurrency, why not consider another language such as F#? Now that F# is a first-class citizen within Visual Studio going forward, there can be a strong case made. Given some of the features of F#, which we will discuss, could potentially be a happy marriage with Axum. The F# language and its associated libraries have many of the constructs that are essential to an agent-based messaging system, including immutability (albeit shallow), encouraging side effect free programming, and library functions such as the mailbox processor messaging classes.

In Praise Of Immutability

In the world of concurrency we find that shared mutable state is evil. Often we have to protect certain parts by using low level constructs such as locks, semaphores, mutexes. Because of this, we find that most people tend to avoid concurrency programming as it tends to be too hard to get just right. Instead, communication through message passing in languages such as Axum and Erlang, immutability is the standard. This way, we can freely reference the values without any worry of whether they will change underneath us. Providing first-class support for immutability goes a long way towards making safe concurrency programming easier for the masses. With the F# language, we get that approach by default and with rich types such as records, discriminated unions, lists, tuples and more.

Of particular note, Discriminated Unions are quite useful in messaging systems to define the types of messages your system accepts. For example, we could model our auction messages quite easily using discriminated unions to define which interactions are legal, such as the following code:

type AuctionMessage =
  | Offer of int * MailboxProcessor<AuctionReply>
  | Inquire of MailboxProcessor<AuctionReply>
and  AuctionReply =
  | Status of int * System.DateTime
  | BestOffer
  | BeatenOffer of int
  | AuctionConcluded of 
      MailboxProcessor<AuctionReply> * MailboxProcessor<AuctionReply>
  | AuctionFailed
  | AuctionOver

In this case, we have succinctly defined what messages can be processed. Adding to this, Axum, through the use of data-flow networks and channel protocols could be a nice compliment to determine how these messages are processed. Where else could they match up nicely?

Built For Concurrency

To talk about a potential marriage between F# and Axum, we need to talk about the language and its libraries and how they support concurrency. From first class events, to asynchronous workflows, to mailbox processors, F# has a wide array of asynchronous and parallel programming libraries available out of the box. In particular, the asynchronous workflows and the mailbox processor could match well with the Axum programming model. Interestingly, Luca Bolognese has built upon the mailbox processor for his LAgent framework to show some more interesting scenarios where agent based programming could work. This includes such things as advanced error handling, hot swapping, implementing MapReduce and so on.

With little effort, we can model such things as the standard ping-pong example using F# mailboxes:

let (<--) (m:MailboxProcessor<_>) msg = m.Post(msg)
type PingMessage = Ping of MailboxProcessor<PongMessage> | Stop
and  PongMessage = Pong

let ping iters (pong : MailboxProcessor<PingMessage>) =
  new MailboxProcessor<PongMessage>(fun inbox -> 
    pong <-- Ping inbox
    let rec loop pingsLeft = async { 
      let! msg = inbox.Receive()
      match msg with
      | Pong -> 
          if pingsLeft % 1000 = 0 then
            printfn "Ping: pong"
          if pingsLeft > 0 then
            pong <-- Ping inbox
            return! loop(pingsLeft - 1)
          else
            printfn "Ping: stop"
            pong <-- Stop
            return () }
    loop (iters - 1))
            
let pong () =
  new MailboxProcessor<PingMessage>(fun inbox -> 
    let rec loop pongCount = async { 
      let! msg = inbox.Receive()
      match msg with
      | Ping sender -> 
          if pongCount % 1000 = 0 then
            printfn "Pong: ping %d" pongCount
          sender <-- Pong
          return! loop (pongCount + 1) 
      | Stop -> printfn "Pong: stop"; return () }
    loop 0)

let ponger = pong()
let pinger = ping 100000 ponger
pinger.Start()
ponger.Start()

And you’ll notice from all of this, there are no mutable values anywhere nor shared global state and all communication happens through message passing. We have certain limitations here such as we cannot remote these calls, so all interaction happens inside the single application. Not only that, but how do we enforce no shared state?

What Would It Look Like?

So, now that we looked at some of the reasons why F# and Axum might be a good marriage, what might it actually look like? That’s a great question! Some of the concepts from Axum could map perfectly to F# whereas some might need a little more coaxing. Let’s go back to the basic building blocks of Axum. They consist of the following:

Agents and domains
Channels
Schema
Networks

The first three items are concerned mostly with state isolation and the exchange of information between our isolated regions of our application, while the last item deals more with the how messages are passed.

The domain is the most basic isolation concept where all data is encapsulated and only constructors are exposed outside of the domain definition. Agents are defined to run within the isolated space of a domain with each agent on a separate thread of control. These agents are exposed to one another through passing messages back and forth via channels which define ports through which our data flows. The data that passes between our domains can be defined in a schema, similar in nature of XML Schemas, to define structure and rules of our data. Now to think about message passing, F# already has asynchronous behavior already built in to the mailbox processor, so we could take advantage here and build on top of it and our networks could guide us as to what order messages are passed.

Let’s look at some possible code examples of what things might look like. I’ll choose just a couple as they might work nicely out of the box. Let’s first look at how we might define a port which accepts a given message.

type ProductInput = Multiply of int * int | Done
type ProductOutput = Product of int | AckDone

This way, we could define what our payload type for both incoming and outgoing. Another area would be to look how schemas might be done. In our earlier example, we used simple data types such as integers, but what about more complex types? Using F#, we could think of using records here to simulate the not only the data, but what is and is not required:

type PersonSchema = 
  { Name     : string
    Employer : string
    Age      : int option }

let matt =
  { Name = "Matthew Podwysocki"
    Employer = "Microsoft Corporation"
    Age = None }

By marking the fields we require as standard fields and those which are optional as option types works out nicely. Using F#, we’re able to have concise syntax with a language that is already defined and quite flexible.

Conclusion

As you can see from this post, a potential marriage between Axum and F# would certainly be a great fit. Instead of focusing on Axum as a separate language, focusing the effort on top of an existing language which matches many of the design goals can bear a lot of fruit. I believe Axum is important for the .NET programming stack, giving us more options on how to deal with concurrency and changing hardware architectures. What do you think?

Generically Constraining F# – Part I

Matthew.Podwysocki — Mon, 14 Sep 2009 22:44:29 GMT

Generic constraints inside .NET has always been a fun enterprise, especially given how C# handles them There has been some discussion on Jon Skeet’s blog about the fact that C# does not allow for generic constraints referring to a number of types. These include:

System.Array
System.Delegate
System.Enum
System.Object
System.ValueType

This is indeed a bit unfortunate, as it limits some of the more interesting applications. The example Jon shows is indeed illegal in C#:

public static T[]GetValues<T>() where T : struct, System.Enum
{
    return (T[]) Enum.GetValues(typeof(T));
}

However, as Jon correctly points out, this is indeed supported by the CLR directly. In fact, with our knowledge of F# constraints, we can write this exact function in F# without any such issue. It’s little wonder that F# has learned some of their lessons from C#, but as well as having the language designed by the person who brought generics to .NET also helps.

Let’s first look at our F# implementation. The idea here is to ensure that our T type as above is an enum. In order to do so, we must specify it is of type enum<underlying-type> where the underlying type is most usually an Int32. Remember, enums can be of any integral besides char, so that’s why it must be specified.

namespace Codebetter.Constraints

module Constraint =

  open System

  let getValues<'a, 'b when 'a : enum<'b>>() =
    Enum.GetValues(typeof<'a>) :?> 'a array

As we can see from the above code, it’s rather straight forward. We specify the ‘a must be an enum of an inner type of ‘b. We could have simplified this for an external call to export it using an int as our ‘b, but let’s keep this as generic as possible. Calling this code, we can get arrays of all values. Let’s test in F# interactive:

> Constraint.getValues<System.IO.FileAccess,int>();;
val it : System.IO.FileAccess array = [|Read; Write; ReadWrite|]
> Constraint.getValues<string,int>();;

  Constraint.getValues<string,int>();;
  ^^^^^^^^^^^^^^^^^^^^

error FS0001: The type 'string' is not a .NET enum type

In our first example, we call with System.IO.FileAccess in which it gives us the three enum values, and in our second case, we tried with a non-enum type of string and sure enough it tells us as much. But, what about C# here? Could this code transfer? In some C# calling code, we could then use our function as follows:

static void Main(string[] args)
{
    var values = Constraint.getValues<FileAttributes, int>();
    foreach(var value in values) Console.WriteLine(value);
}

This will give us the expected results of all values for the FileAttributes enum just as we would through our F# code. An issue arises, however, when we try with a failure case as we had above:

var values = Constraint.getValues<string, int>();
foreach (var value in values) Console.WriteLine(value);

This will compile just as our previous example did. When we run this example, however, we get an exception thrown due to Enum.GetValues expecting an enum type as we have below and our constraint not honored.

Unhandled Exception: System.ArgumentException: 
Type provided must be an Enum.
Parameter name: enumType
   at System.Enum.GetValues(Type enumType)
   at Codebetter.Constraints.Constraint.getValues[a,b]() 
   in C:\Work\ConstraintLib\Module1.fs:line 19

So, the important thing to remember is that even if other languages export generic restrictions such as an enum, C# will not honor this restriction. Other restrictions such as reference type restrictions such as the following work well:

let printClass<'a when 'a : not struct> (arg:'a) =
  printfn "%A" arg

And the calling C# code:

Constraint.printClass("Hello") // prints Hello
Constraint.printClass(3) // error CS0452

By the code above, we sure enough have the compiler honoring our generic restrictions in this case.

Conclusion

We’re just getting started here in this brief series to cover generic constraints. There are a few more to talk about before we’re done such as method signature restrictions, constructor restrictions and so forth. I hope at some interation that generic restrictions in C# get revisited to make them as fully features as F#’s.

No:SQL (east) 2009

Matthew.Podwysocki — Thu, 10 Sep 2009 04:28:27 GMT

As you may have noticed, there has been a lot of talk around NOSQL “movement” lately. The name, NOSQL was created to describe non-traditional data storage engines and techniques to address concerns of data sets of horizontal scale. Innovations such as Google’s BigTable and Amazon’s Dynamo have led to a rise in a new wide variety of new technologies and ideas around pointed problems as data sets at scale, like CouchDB, Redis, MongoDB, Cassandra, Voldemort and many more. These NOSQL technologies have little unifying them together as they use such techniques as Column-Oriented, Key-Value Stores, CAP Theorem, and no one to rule them all, but underlying them is that they are different than the “traditional” RDBMS solutions of SQL Server, Oracle, MySQL and so on. These NOSQL solutions are starting to turn up in good numbers for specific use cases and not meant to be the end all solutions.

Together with Brad Anderson and Chris Williams, we’ve launched No:SQL (east) 2009 which aims to present experiences of different companies using these NOSQL solutions in production. Following the success this summer of the NOSQL Meetup in San Francisco, we bring the discussion back east to Atlanta, GA from October 28th-30th. A wide array of experiences will be shared on such projects as Cassandra, Redis, MongoDB, CouchDB as well as the Microsoft Research projects Dryad and DryadLINQ. Some of the highlighted sessions include:

Arin Sarkissian (Digg): Cassandra
Kevin Smith (Hypothetical Labs): Redis
Don Brown (Twitpay): Pig
Chris Curtin (Silverpop): Cascading
John Hornbeck (Engine Yard): MongoDB
Mike Miller (Cloudant): CouchDB
Cliff Moon (Microsoft / Powerset): Dynomite
Justin Sheehy (Basho): Riak
Mark Gunnels (Catamorphic Labs): HBase
Tim Anglade (af83): tin
Emil Eifrem (Neo Technology): Neo4j
Yuan Yu (Microsoft Research): Dryad / DryadLINQ
Geir Magnusson (Gilt Groupe): Voldemort

More information, including registration, can be found at the site: https://nosqleast.com/2009/. Hope to see you there!

[ANN] DC ALT.NET 9/10/2009 – Webmachine with Kevin Smith

Matthew.Podwysocki — Fri, 04 Sep 2009 19:27:31 GMT

This month, DC ALT.NET is moving the meeting a little forward this month and teaming with NOVALANG and the Erlang Users of Arlington/DC to talk about the Webmachine REST Toolkit. We at DC ALT.NET continue to strive to push developers to look outside their normal surroundings and comfort zones and this month is no different. Details are below:

Getting Some REST with Erlang and Webmachine

Kevin Smith of Hypothetical Labs will be speaking about WebMachine: an erlang REST toolkit which makes it easy to develop HTTP interfaces using Erlang. Providing RESTful interfaces is quickly becoming the norm for modern websites. There's more to REST than handling GETs and POSTs, though. This talk will illustrate how the combination of Erlang and webmachine simplifies and speeds the development of REST resources.

About Kevin Smith

Kevin Smith has, at various times, been a network administrator, DBA, developer, team lead and trainer over his 14 year career. He ﬁrst learned about Erlang in 2006 via Joe Armstrong's excellent “Programming Erlang” and has never looked back. He attended the first (and only?) Erlang Studio where he was asked to produce what became the popular PragProg screencast series "Erlang In Practice". Until recently, Kevin was a developer at Engine Yard where he worked on a distributed systems management application using Erlang. Kevin founded Hypothetical Labs in April of this year to focus on Erlang full time. He is also the co-author of the upcoming book "Erlang Web Application Development".

Date/Time: 9/10/2009 – 7-9PM

Location:
The Motley Fool
2000 Duke Street
Alexandria, VA 22314

F# First Class Events – Async Workflows + Events Part III

Matthew.Podwysocki — Fri, 04 Sep 2009 04:49:19 GMT

So far in this series, I’ve covered a bit about what first class events are in F# and how you might use them. In the first post, we looked at what a first class events mean and some basic combinators in order to compose events together. In the second post, we looked at how we might create events and publish them to the world through classes. And in the third post I talked about how to manage the lifetime of a subscription. In the fourth installment, I corrected my usage of the old create function and instead to use the Event class to create, trigger and publish events. In the last part, we’ve been talking about asynchronous workflows and eventing together, and this time we’ll pick up on that discussion. Before we get started, let’s get caught up to where we are today.

Converting Events to Asynchronous Operations

One of the last topics to be covered in this section involves the question, “How do we take an event and properly manage the cancellation and error checking?” Earlier I showed about how we could take the WebClient’s DownloadStringAsync event and partition it into three different events based upon the outcome of the main event. This time, we’re going to take that event and turn it into an asynchronous operation with proper error checking and cancellation checking.

In order to make this happen, we need to use the AwaitEvent extension method on the Async<T> class. Let’s take a first glance at how to do this with a BackgroundWorker class. This class allows us to do potentially expensive operation in the background and report progress along the way. Of interest to us is the RunWorkerCompleted event and the RunWorkerAsync method in trying to wrap that in such a way that we can check for errors and cancellations. First, let’s create an extension method to the BackgroundWorker class to allow for the Async<T> binding.

open System
open System.ComponentModel

type BackgroundWorker with
    member this.AsyncRunWorker(?argument:obj) =
    async { // Run the worker asynchronously
            let arg = defaultArg argument null
            this.RunWorkerAsync(arg)
              
            // Wait for the event to happen
            let! args = Async.AwaitEvent(this.RunWorkerCompleted, 
                                         cancelAction=this.CancelAsync)
              
            // Base our result on what happened
            let result = 
              if args.Cancelled then
                AsyncCanceled (new OperationCanceledException())
              elif args.Error <> null then AsyncException args.Error
              else  AsyncOk args.Result 
            return! AsyncResult.Commit(result) }

What I’ve done is to create an extension method called AsyncRunWorker which has an optional argument to send to the worker. I first call the RunWorkerAsync with our argument (null if omitted), then I wait for the RunWorkerCompleted event to fire with our cancel action. This cancel action allows us to specify some behavior that happens should the operation somehow be canceled. Next, we base our result upon whether we have a cancellation, an error or lastly, we have a result. Then we commit that answer as our result. This function, when called, will produce and Async<obj> as that is the signature of the args.Result.

We can test the behavior of this by creating a simple worker and running it inside of an async workflow. In order to do so, we’ll put in a little bit of infrastructure that we had in a previous post talking about subscribing to events. This way, we can unsubscribe from our event automatically at the end of our async workflow through the use of a using scope.

[<AutoOpen>]
module EventExtensions = 
  open System

  type IDelegateEvent<'Del when 'Del :> Delegate > with
    member this.Subscribe(d) =
      this.AddHandler(d)
      { new IDisposable with
          member disp.Dispose() =
            this.RemoveHandler(d) }

After we’ve defined this, let’s go ahead and now define our async workflow with the BackgroundWorker defined. In this instance, we’ll create a simple background process that waits for a little bit and then formats the argument into a string as the result.

let workerResult (worker:BackgroundWorker) =
  async { use e = worker.DoWork.Subscribe(fun _ args -> 
                                  Thread.Sleep(5000)
                                  args.Result <- sprintf "Hello %A" args.Argument)
          return! worker.AsyncRunWorker ("Matt") }
  |> Async.RunSynchronously

In this instance, we created a function which takes a BackgroundWorker and inside the async workflow, we subscribe to the DoWork event to sleep for a bit, and then format a string with the argument. At the end of the async block, I invoke the AsyncRunWorker extension method with my first name as an argument. Finally, I run it synchronously just to force the evaluation. Had I been using .NET 4.0, I could have used a Task<T> instead and invoked it as a future. I’ll cover how that works in a future post.

Now that we have our function defined for handling a BackgroundWorker inside the async workflow, let’s tie it all together. First, we’ll create the worker which supports cancellation. One item of note is that I included below some pragmas for fixing some thread blocking issues when using F# interactive around the use of SynchronizatonContexts and the Async.RunSynchronously. If this code is compiled and run as an executable, then it won’t be affected. I invoke the worker three times and print out the result of each.

let worker = new BackgroundWorker(WorkerSupportsCancellation = true)

#if INTERACTIVE
let context = SynchronizationContext.Current
SynchronizationContext.SetSynchronizationContext(null)
#endif

workerResult worker |> printfn "%A"
workerResult worker |> printfn "%A"
workerResult worker |> printfn "%A"

#if INTERACTIVE
SynchronizationContext.SetSynchronizationContext(context)
#endif
do ()

It’s an interesting exercise, but how about something a bit more useful?

Extending WebClient

In this case, let’s look at extending the System.Net.WebClient to also support F# async workflows for such things as asynchronously opening a reader of a given URL. If you’ll look at the F# PowerPack library, it already has an extension method for asynchronously downloading a string, such as HTML from a website in WebClient.AsyncDownloadString. For my example, let’s try the same approach from above to apply it to our situation:

open System
open System.IO
open System.Net
 
type WebClient with
  member this.AsyncOpenRead (address:Uri) : Async<Stream> =
    async { let userToken = new obj()
            this.OpenReadAsync(address, userToken)

            // Loop until we see a reply with the same token
            let rec loop() = 
              async { let! args = 
                Async.AwaitEvent(this.OpenReadCompleted,
                                 cancelAction=this.CancelAsync)
                      if args.UserState <> userToken then return! loop()
                      else
                        let result = 
                          if args.Cancelled then 
                            AsyncCanceled (new OperationCanceledException())
                          elif args.Error <> null then AsyncException args.Error
                          else  AsyncOk args.Result 
                        return! AsyncResult.Commit(result) }
            return! loop() }

In this case, we’re going to create a token in which we can track our particular instance of the async operation. We call the OpenReadAsync method with our address and our token, and then we loop until we get the callback with our associated token. Once we do, then we set the result much as we did above. You’ll notice a familiar trend that most of the async operations on the WebClient can be extended the same way this one was, such as OpenWrite, DownloadXXX and UploadXXX.

We can now download data from a reader as we have in this example below:

open System
open System.IO
open System.Net
open System.Threading

let readHtml (address : Uri) =
  async { let wc = new WebClient()
          use! stream = wc.AsyncOpenRead(address)
          use reader = new StreamReader(stream)
          return! reader.AsyncReadToEnd() }

#if INTERACTIVE
let context = SynchronizationContext.Current
SynchronizationContext.SetSynchronizationContext(null)
#endif

let html = 
  readHtml(Uri "http://bing.com") 
  |> Async.RunSynchronously

#if INTERACTIVE
SynchronizationContext.SetSynchronizationContext(context)
#endif
do()

So, as you can see from above, we simply read the HTML from a page using the WebClient approach instead of the WebRequest way using async workflows. Once again, we have to deal with the context issues only during F# Interactive.

Conclusion

From these two examples, we can see how you can take programming models built around events and turn them into async functions that can easily interact with F#’s async workflows. I think over this past series we’ve covered quite a bit dealing with first class events in F#. In the next series, we’ll start to look at the Reactive Framework and new ways of thinking around handling events.

F# First Class Events – Async Workflows + Events Part II

Matthew.Podwysocki — Wed, 02 Sep 2009 15:55:56 GMT

So far in this series, I’ve covered a bit about what first class events are in F# and how you might use them. In the first post, we looked at what a first class events mean and some basic combinators in order to compose events together. In the second post, we looked at how we might create events and publish them to the world through classes. And in the third post I talked about how to manage the lifetime of a subscription. In the fourth installment, I corrected my usage of the old create function and instead to use the Event class to create, trigger and publish events. Last time, we’ll look at how we can use first class events inside Async Workflows in order to do such items as tracking state. This time, let’s look at how we could use the Async Workflows together with events in order to draw on a WPF window. Before we get started, let’s get caught up to where we are today.

Drawing the Easy Way

In our last post, we had a simple click tracker, which in itself is interesting, but not all that useful. This time, let’s take another approach and create a little drawing application in WPF using the async workflows and events together. In order to do so, let’s get a little infrastructure out of the way before we get to the real heart of the matter. First, we need the ability to grab the position of our mouse at any given time. In order to do so, we’ll get the position relative to our given input element.

open System.Threading
open System.Windows
open System.Windows.Controls
open System.Windows.Input
open System.Windows.Markup
open System.Windows.Media
open System.Windows.Shapes

let getPosition (e : #IInputElement) (args : #MouseEventArgs) =
  let pt = args.GetPosition e
  (pt.X, pt.Y)

This code is rather straight forward which simply gets the position of our mouse relative to our input element. Next, we need to create an event which fires while our left mouse button is down and our mouse is moving. In order to do so, we’ll merge the MouseLeftButtonDown and MouseMove events from our given input element so that it only fires when both happen. After we define the event, we’ll create an extension method on the IInputElement interface to expose this event.

let createMouseTracker (e : #IInputElement) = 
  e.MouseLeftButtonDown
  |> Event.map (fun args -> args :> MouseEventArgs)
  |> Event.merge e.MouseMove
  |> Event.filter (fun args -> args.LeftButton = MouseButtonState.Pressed)
  |> Event.map (getPosition e)

type System.Windows.IInputElement with
  member this.MouseTrack = createMouseTracker this

The function we defined above first captures the MouseLeftButtonDown event, and then we want to downcast the MouseButtonEventArgs down to the MouseEventArgs so that we can merge it with the MouseMove event, due to the fact that both events must have the same type of arguments. After that, we ensure that we’re firing only when the left mouse button is down, and then finally we map our mouse event arguments to obtain only the x and y coordinates.

After defining our event and exposing it as an extension method, we need a way to draw a line from one coordinate to the next. In order to do so, we’ll simply need our from coordinates, our to coordinates and our element which holds it.

let drawLine stroke (x1, y1) (x2, y2) (e : #IAddChild) =
  let line = 
    new LineGeometry(StartPoint = Point(x1, y1), EndPoint = Point(x2, y2))
  let path = 
    new Path(Stroke = stroke, StrokeThickness = 5., Data = line)
  e.AddChild(path)

Our draw line function from above simply creates a LineGeometry with our starting and end points, then we create a Path to store our line and brush data, and finally add it to our element. Now, to the heart of the matter. How might we track our mouse using these Async Workflows and events together? In the last post, we looked at using the recursive loops to store state, such as the number of times a button was clicked. This time, we can store the previous coordinates as our loop argument, but in order to make this work, we need to fire it one time and then initialize the loop. Let’s look at the code and go into detail below:

let trackMouse (e : #UIElement) (guiContext : SynchronizationContext) =
  let rec firstEvent () =
    async { let! args = Async.AwaitEvent e.MouseTrack
            return! loop args } 
  and loop prev =
    async { let! current = Async.AwaitEvent e.MouseTrack
            do! Async.SwitchToGuiThread guiContext
            do drawLine Brushes.Red prev current e
            do! Async.SwitchToThreadPool()
            return! loop current }
  firstEvent()

As you can see, our track mouse function takes our element and a synchronization context. This context allows us to switch back and forth from the thread pool to the GUI thread at any point, which can be crucial for UI rendering. Our first function initializes the loop function by getting the first instance of the loop with the first coordinates. In the loop function, we await our instance of the event, we switch to the GUI context, draw our line, switch back to the thread pool and then recurse again to await the next instance of our mouse track event. Now, let’s tie this whole thing together.

let window = new Window(Visibility = Visibility.Visible)
let canvas = new Canvas(RenderSize = window.RenderSize, 
                        Background = Brushes.AliceBlue)
window.Content <- canvas
let guiContext = SynchronizationContext.Current

trackMouse canvas guiContext |> Async.Start

First, we create our window which holds the application and then we create a canvas which allows us to draw arbitrary shapes upon it. After getting the GUI context, we can invoke our trackMouse function with our canvas and our context and then asynchronously starting it. Our end result looks something like the following:

You might imagine that we could indeed change colors as well as part of our state. Of course there’s an issue with once we lift up our mouse to reset the previous coordinate, but that’s an issue for another post.

Conclusion

Once again, using this naive example, we’re able to see that asynchronous workflows and first class events can indeed work nicely together to do simple things such as drawing. In the next post, we’ll go after how to handle the cancel events with such things as asynchronously downloading data. After this, we’re not quite finished here as we have a lot more to cover with event-based programming with such things as the Reactive Framework (Reactive LINQ).

F# First Class Events – Async Workflows + Events Part I

Matthew.Podwysocki — Mon, 31 Aug 2009 20:37:08 GMT

So far in this series, I’ve covered a bit about what first class events are in F# and how you might use them. In the first post, we looked at what a first class events mean and some basic combinators in order to compose events together. In the second post, we looked at how we might create events and publish them to the world through classes. And in the third post I talked about how to manage the lifetime of a subscription. Last time, I corrected my usage of the old create function and instead to use the Event class to create, trigger and publish events. This time, we’ll look at how we can use first class events inside Async Workflows in order to do such items as tracking state.

Awaiting Events

You may have noticed me talk a bit about asynchronous programming and event-based programming both in F#, but what about bringing the power of both of them together? What if we could somehow interact with first class events inside of async workflows to wait for an event and then continue when that event happens? Inside the F# PowerPack, there is an extension method to do exactly that. The AwaitEvent extension method to the Async<T> class takes an event and an optional cancellation action and returns an async binding for our event so that we can wait for a single invocation of the event and then use its event arguments. Let’s look at the signature below.

type Microsoft.FSharp.Control.Async<'T> with 
  static member AwaitEvent: 
    IEvent<'Delegate,'T> * ?cancelAction : (unit -> unit) -> Async<'T> 
      when 'Delegate : delegate<'T,unit> and 'Delegate :> System.Delegate

What you’ll notice is that this returns an asynchronous computation and takes the event, which it listens to once and then disposes once it is completed or cancelled. If the cancellation action is specified and a cancellation occurs, then the function is executed and will continue to wait for the event, however, if not specified, then the computation is immediately halted.

Typically, when we’re talking about aggregating data as I’ve stated above, we might consider the scan combinator from the Event module. This allows us, with a given seed, to aggregate data as it comes in. Given a quick use of a WPF window, it might look like the following:

open System.Windows

let window = new Window(Visibility = Visibility.Visible)
window.MouseDown
  |> Event.scan (fun acc args -> args.ClickCount + acc) 0
  |> Event.listen (printfn "Clicked %d time(s)")

This above code allows us to count the number of times a mouse is clicked and display that on F# interactive. Pretty simple code, but how might we handle cancellation or even how to stop listening for this? Well, given this example, not so easily. So, how can we use async workflows instead? Let’s try the above example using the new technique:

open System.Windows

let window = new Window(Visibility = Visibility.Visible)

let trackClicks (e : #UIElement) = 
  let rec loop (n:int) =
    async { let! args = Async.AwaitEvent e.MouseDown
            let clickCount = args.ClickCount + n
            printfn "Clicked %d time(s)" clickCount
            return! loop clickCount }
  loop 0

trackClicks window |> Async.Start

What this code does is first create a WPF window which we’ll use later for tracking the mouse clicks. Next, we define a function called trackClicks which takes in an a UIElement for which to track mouse clicks. Inside, we have a loop, because we remember that these event waiting functions only wait one time in which we seed the click count to zero. Inside of our loop function, we get the arguments from our MouseDown event so that we can get the number of clicks given to us, we increment the click count, print it, and then return to the loop again so that we keep listening for click events. Finally, we start listening by calling our trackClicks function with our window argument and then starting it asynchronously. The output from our little application might look like this from F# Interactive just as it should have for the above example:

Clicked 1 time(s)
Clicked 3 time(s)
Clicked 6 time(s)
Clicked 7 time(s)
Clicked 8 time(s)
Clicked 10 time(s)
Clicked 13 time(s)
Clicked 17 time(s)
Clicked 18 time(s)
Clicked 20 time(s)

We get the same exact behavior as we would above, but yet gives us some more power over such things as cancellation, alternate paths, etc.

Conclusion

From this naive example, we’re able to see that asynchronous workflows and first class events can indeed work nicely together. In the next couple of posts, we’ll go deeper into this subject to explore such areas as drawing on a screen as well as downloading data from a site asynchronously. After this, we’re not quite finished here as we have a lot more to cover with event-based programming with such things as the Reactive Framework (Reactive LINQ).