Matthew Podwysocki's Blog

Introduction to the Reactive Framework Part V

podwysocki — Wed, 18 Nov 2009 14:48:00 PST

In the previous post of the Introduction to the Reactive Framework series, we covered how to create new IObservable<T> instances, either from scratch or from existing sequences. What this allowed us to do was turn an operation which was previously interactive, such as iterating over a collection, to a reactive, where I could have multiple listeners reacting to the same collection concurrently. This has nice implications for allowing us to scale our application in interesting ways. This time, let’s take another angle on making asynchronous programming easier.

Let’s get caught up to where we are today:

From Asynchronous To Observables

In the first post in the series, we talked about some of the problems we face with asynchronous programming today. For example, for any given operation, how do we handle exceptions, or handle cancellation, or even manage the lifetime of resources? Let’s take a look at the story of asynchronous programming today. For example, let’s take the fairly straight forward approach of sending a tweet in Twitter, but with the added pressure of non-blocking calls for all IO operations. Now we took an example which should have been straight forward, and now it looks something like this anti-pattern:

var request = WebRequest.Create("http://twitter.com/statuses/update.xml");
request.Credentials = new NetworkCredential("foo", "bar");
request.Method = "POST";

request.BeginGetRequestStream(rsAr =>
{
    var requestStream = request.EndGetRequestStream(rsAr);
    var tweet = HttpUtility.HtmlEncode("status=Hello from an async method #bacon");
    var bytes = Encoding.UTF8.GetBytes(tweet);
    requestStream.BeginWrite(bytes, 0, bytes.Length, beginWriteAr =>
    {
        requestStream.EndWrite(beginWriteAr);
        request.BeginGetResponse(responseAr =>
        {
            var response = request.EndGetResponse(responseAr);
            var responseStream = response.GetResponseStream();

            var readBuffer = new byte[response.ContentLength];
            responseStream.BeginRead(readBuffer, 0, readBuffer.Length, readAr =>
            {
                var read = responseStream.EndRead(readAr);
                var readText = Encoding.UTF8.GetString(readBuffer);
                ResultsText.Text = readText;
            }, null);
        }, null);
    }, null);
}, null);

Not only is this code an absolute mess, but it has a number of bad practices, including not handling cleanup of our resources, as well as not handling exceptions, cancellation checking, or even checking if our buffer was completely read. Adding those constraints to the above code would make it a bit more unreadable. The situation we run into is that programming in a non-blocking fashion has caused all sorts of heartache where we become so wrapped up in the non-blocking code that we lose sight easily of the domain logic we should have been interested in, in the first place.

I’ve covered in the past that with F# async workflows, solving this is a rather easy task and that kind of rich functionality has been unavailable to C# developers directly. But, with the Reactive Extensions for .NET, we have the ability to also take advantage of composable asynchronous actions as well. So, where do we get started?

Let’s take a simple example of creating a function and then invoking it asynchronously.

Func<int, int, int> add = (x, y) => x + y;

add.BeginInvoke(3, 4, ar =>
{
    var result = add.EndInvoke(ar);
    Console.WriteLine(result);
}, null);

Many asynchronous methods in .NET are written in this way that their signature has a BeginXXX and EndXXX where the XXX is the method name that is being executed asynchronously. The Begin takes the arguments to execute the method, an AsyncCallback which is an action that takes an IAsyncResult and returns nothing, and finally object state. The End method takes the IAsyncResult which is passed in from the AsyncCallback in order to retrieve the value of the asynchronous call.

void BeginXXX(args, AsyncCallback, state);

Value EndXXX(IAsyncResult);

Luckily, the Reactive Extensions give us a couple of ways to make this happen. First, let’s take an existing method such as the System.IO.Stream.WriteAsync. In this example, we’ll create an extension method which allows us to turn this asynchronous method into a IObservable<T>.

public static IObservable<Unit> WriteAsync(
    this Stream stream, 
    byte[] buffer, 
    int offset, 
    int count)
{
    return Observable.FromAsyncPattern<byte[], int, int>(
        stream.BeginWrite,
        stream.EndWrite)(buffer, offset, count);
}

Because the Write method returns void, we have issues in C# as we cannot have a generic type as being void. To get around this, much like F#, the Reactive Extensions introduced the Unit type to express that we have no value. Quite frankly this is the way I think C# should have been to allow for this and not need these unnecessary hacks. Anyways, the Observable class has a method called FromAsyncPattern which takes in both the BeginXXX and EndXXX and returns a Func delegate that takes the arguments required to execute it. In this case, the Observable.FromAsyncPattern returns a Func which takes the buffer, offset and count and returns an IObservable<Unit>.

There is also another way in that we can take our existing add function from above and using an extension method called ToAsync, can also work the IObservable magic.

Func<int, int, int> add = (x, y) => x + y;
Func<int, int, IObservable<int>> obvervableAdd = add.ToAsync();

IObservable<int> result = from added in obvervableAdd(3, 4)
                          select added;
IDisposable sub = result
    .SubscribeOnDispatcher()
    .Subscribe(added => Results.Text = added.ToString());

In this instance, we took our existing add method and then turned it into an asynchronous method by using the ToAsync extension method. That returns a Func delegate which takes our two arguments and returns an IObservable<int> which contains our asynchronous result. We can then take our new observableAdd and execute it inside of a LINQ statement, then subscribe to it on the Dispatcher thread in order to rid ourselves of synchronization context issues in WPF.

Going back to our original example here, let’s see how we might follow some of the ideas presented here into creating a way to send a tweet completely in a LINQ statement.

var tweetObservable =
    from request in 
        CreateWebRequest(
            "http://twitter.com/statuses/update.xml", 
            userName, 
            password, 
            "POST")
    let tweet = HttpUtility.HtmlEncode("status= Hi! #bacon")
    let buffer = Encoding.UTF8.GetBytes(tweet)
    from _ in request.SetContentLength(buffer.Length)
    from requestStream in request.GetRequestStreamAsync()
    from __ in requestStream.WriteAsync(buffer, 0, buffer.Length)
    from response in request.GetResponseAsync()
    let responseStream = response.GetResponseStream()
    let reader = new StreamReader(responseStream)
    select reader.ReadToEnd();
    
var tweetsObservable = tweetObservable
    .Throttle(TimeSpan.FromMinutes(3))
    .Repeat(25);

We can create extension methods to the WebRequest for GetRequestStream and GetResponse to enable observable behavior via the Begin/End methods that the WebRequest exposes. As well, we can extend the System.IO.Stream as well to both write and read streams asynchronously. We have other more trivial methods such as setting the content length and creating a web request as an observable as well, and in order to do that was covered in the previous post using the Observable.Create method. After we create this IObservable value, we can then throttle it to every three minutes and to repeat 25 times. One concern we might have is around the resource usage and ensuring the cleanup, and we’ll cover that next time.

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 as well as managing resources, and turning Tasks Observables.

Reactive Extensions for .NET (Rx) released on DevLabs

podwysocki — Tue, 17 Nov 2009 14:51:00 PST

As you may have noticed, I’ve been blogging a bit about the Reactive Framework, now the Reactive Extensions for .NET (Rx) and how it will change the way we approach asynchronous and event-based programming. Just as LINQ to Objects changed the way we deal with collections, The Reactive Extensions will change the way we deal with asynchronous and event-based programming. Fast forward to today, Rx has been released on Microsoft DevLabs for not only .NET 4 Beta 2, but also .NET 3.5 SP1 and Silverlight 3 as well.

If you’re not familiar with Rx, it is a library for composing asynchronous and event based programs together using observable collections (IObservable<T>). This is especially important in the development of Silverlight, which disallows blocking networking and threading calls from happening and instead forces you into an asynchronous model, but just as well, it’s quite useful for other applications such as traditional desktop applications and web applications. With that comes its own set of challenges. How do I compose these asynchronous events together? How do I handle exceptions? How about cancellation?

The Reactive Extensions, the contain a superset of the standard LINQ operators we’ve come to know and use quite frequently in our applications which are based not off the IEnumerable<T>, but instead IObservable<T>. The IObservable<T>/IObserver<T>, being the mathematical dual of IEnumerable<T>/IEnumerator<T> allows us to go from the pull model to the push model with ease. With that, we can create abstractions over asynchronous methods, events, Parallel Extensions for .NET Tasks, StreamInsight, F# First Class Events and more.

Download it today and give the team feedback.

Introduction to the Reactive Framework Part IV

podwysocki — Sun, 15 Nov 2009 15:55:00 PST

In the previous post in this series, we covered how to turn .NET events into first class values through IObservable instances. By doing so, we were able to do much more interesting things than just subscribe and unsubscribe, instead we were able to create a mouse drag event with little effort through composition. In this post, let’s look at going from push to pull by turning collections into IObservable<T> instances.

Let’s get caught up to where we are today:

From IEnumerables To Observables

As you may remember from the first post and second post in this series, we covered going from IEnumerable<T> to IObservable<T> and the duality between the two. But, how can we switch back and forth between them? Remember that we can create an IObservable from a couple of angles. Let’s first create one by using the chaining together Empty and StartsWith combinators on the Observable class to create an IObservable<T>. Note that this is not the publicly available release of the Reactive Framework, so bear with any name changes.

var observable = Observable.Empty<int>()
    .StartWith(1)
    .StartWith(2)
    .StartWith(3);

This allows me to start out with an empty IObservable<int> and then pre-append the value to the front of the instance, so in this case it would render 3, 2, 1. Next, let’s look at how we might generate a sequence IObservable from 1 to 10.

var observable = Observable.Generate(
    1,                        // Initial value
    value => value <= 10,    // Predicate
    value => value,            // Selector
    value => value + 1);    // Iterator
observable.Subscribe(Console.WriteLine);

In this instance, we supply an initial value, then a predicate to determine when to stop, a result selector, and then finally an iterator. There are plenty of overloads as well on the Generate to suit your needs when creating IObservable<T> values. But, what about taking existing IEnumerable<T> values and converting them to IObservable<T> values? One could use the the Create function which allows us to create arbitrary IObservable<T> instances.

var enumerable = Enumerable.Range(1, 10);
var observable = Observable.Create<int>(observer =>
{
    try
    {
        foreach (var item in enumerable)
            observer.OnNext(item);
        observer.OnCompleted();
    }
    catch (Exception exception)
    {
        observer.OnError(exception);
    }

    return () => { };
});
observable.Subscribe(
    value => Console.WriteLine(value),
    exn   => Console.WriteLine(exn.ToString()));

What we’re doing in the above code is using the Create method which gives us an IObserver<T> that we can post values to. In this case, we’re iterating through a collection and for each item, we’re calling OnNext. At the end of the iteration, we call the OnCompleted method which indicates that there are no more values. If there were some sort of exception when iterating the values, it would be caught and the exception posted to the observer. We can then decide how to handle it during our Subscribe method call, if at all. Finally, we return an Action which is to be called once we unsubscribe from the given IObserver<T>, which in this instance, we do nothing. That’s all fine and good, but there is an easier way of course, by using the ToObservable extension method.

var enumerable = Enumerable.Range(1, 10);
var observable = enumerable.ToObservable();
observable.Subscribe(Console.WriteLine);

Going from IEnumerable<T> to IObservable<T> as you an see is quite easy. Just as well, going back is easy as well through either of two methods, one being calling the ToEnumerable extension method, and the other being the GetEnumerator method.

// To Observable
var enumerable = Enumerable.Range(1, 10);
var observable = enumerable.ToObservable();

// And back again
var enumerableAgain = observable.ToEnumerable();
var enumerator = observable.GetEnumerator();

This ultimately leaves us in control of when we want to switch between the pull and push model, depending on our circumstances. It’s sort of like a buy one get one free in that respect. What makes this interesting is to take a collection and spread it out to multiple instances, for example reading in a file and then you could have multiple subscriptions each process the data in turn. Those possibilities are endless if we want to do certain actions concurrently.

var text = File.ReadAllLines("DocumentToProcess.txt");
var textObservable = text.AsObservable();

// Process concurrently
var textLetterSub = text.Subscribe(CountLetters);
var textWordSub = text.Subscribe(CountWords);
var textVowelSub = text.Subscribe(CountVowels);

There are also more things to come when dealing with collections that we’ll get into in later posts in this series, but this is enough for now.

Conclusion

Introduction to the Reactive Framework Part III

podwysocki — Thu, 12 Nov 2009 20:19:00 PST

In my previous post in the Introduction to the Reactive Framework series, I discussed the duality between the IEnumerable/IEnumerator and IObservable/IObserver and how that enables us to generalize the ideas from LINQ to Objects to LINQ to Observables/Events. After the last post, I was asked how we go from events to Observables, so let’s tackle that in this post.

Before we get started, let’s get caught up to where we are today:

From Events...

Let’s start out by looking at the way we’d usually do event-based programming in .NET. First, if we have the need to pass data as arguments to our event, we’ll need to create a class which inherits from EventArgs, and in this case we have a class called SomeEventArgs. This class holds nothing more than just a simple object value.

public class SomeEventArgs : EventArgs {
    public object Value { get; private set; }

    public SomeEventArgs(object value) {
        Value = value
    }
}

Then we’d have a class which exposes an event with an EventHandler of our SomeEventArgs. At some point along the way we’d have a method which invokes our event, keeping in mind that we need to check for nulls before invoking.

public class SomeClass
{
    public event EventHandler<SomeEventArgs> SomeEvent;
    public event EventHandler<SomeEventArgs> OtherEvent;
    
    public void InvokeEvent(object value) {
        var handler = SomeEvent;
        if(handler != null)
            handler(this, new SomeEventArgs(value));
    }
    // Other event invoking code here
}

Now to do something useful with it, you can subscribe and unsubscribe by using the += and –= operators. In this case, I actually declared a method called SomeHandler which will react to the event arguments that I give it.

var someClass = new SomeClass();

// Add handler
someClass.SomeEvent += SomeHandler;

// Remove handler
someClass.SomeEvent -= SomeHandler;

Our SomeHandler method must follow the signature with the sender as an object and the EventArgs derived class, whatever it might be. At this point we react to anything that we’re subscribed to in this method.

private void SomeHandler(object sender, SomeEventArgs e) {
    // Some handler code
}

The problem with this solution is that it isn’t quite compositional. What do I mean by that? What if I want to combine this SomeEvent firing with another event? Or if I want to ensure that an event gets posted on a certain synchronization context? Or if I want to throttle the firing of an event to a certain threshold? All of those are a tad more difficult using standard out of the box .NET events, but, we can with Observables. So, how do we get there?

To Observables

Unlike F#, we don’t get Observables for free when we use events, so we have a little work ahead of us. In order for us to go from events to Observables , we simply need to use the Observable.FromEvent method. There are several flavors that we can use. The first option is to use a little “magic string” juice to wrap our event in an IObservable. This method takes the object to bind for the event and the event name as a string.

public static class EventExtensions {
    public static IObservable<Event<SomeEventArgs>> GetSomeEvent(
        this SomeClass someClass) {
    
    return Observable.FromEvent<SomeEventArgs>(
        someClass, "SomeEvent");
}

This method then returns to us an IObservable<Event<SomeEventArgs>> which allows us to get access to the EventArgs and the Sender through their respective properties on the Event class. Personally, I’m not a fan of magic strings at all and if I can get away with not using them, all the better. Luckily, there are other options. The next option is to use Action<EventHandler<EventArgs>> arguments for both the subscribe and unsubscribe. Keep in mind that this only works for those events which are declared to use EventHandler<TEventArgs>.

public static class EventExtensions {
    public static IObservable<Event<SomeEventArgs>> GetSomeEvent(
        this SomeClass someClass) {
    
    return Observable.FromEvent<SomeEventArgs>(
        h => someClass.SomeEvent += h,
        h => someClass.SomeEvent -= h);
}

If your given event doesn’t have the signature of EventHandler<TEventArgs>, you can still take advantage of the Reactive Framework as well. In this instance, let’s extend the WPF IInputElement to wrap the MouseMove event as an IObservable<Event<MouseEventArgs>>.

public static IObservable<Event<MouseEventArgs>> GetMouseMove(
    this IInputElement inputElement)
{
    return Observable.FromEvent(
        (EventHandler<MouseEventArgs> h) => new MouseEventHandler(h),
        h => inputElement.MouseMove += h,
        h => inputElement.MouseMove -= h);
}

What this does for us behind the scenes is create an IObservable/IObserver to handle the events as they happen. Each invocation of the event causes the OnNext to be fired with the Event<TEventArgs> argument. In this case, the OnComplete and OnException are not implemented as part of the IObserver instance.

An Example

Let’s create a little example of drawing on a canvas in WPF. In order to do that, we’ll need not only the MouseMove extension as we have above, but also MouseLeftButtonDown and MouseLeftButtonUp. Each of those extension methods should follow the same pattern as above in terms of needing the extra parameter to convert the EventHandler<MouseButtonEventArgs> to a MouseButtonEventHandler.

First, we need to capture position of the mouse during our mouse moves. After that, we’ll need to zip together the mouse move and another mouse move that is one ahead in order to capture a delta. Finally, we’ll capture the mouse downs and the mouse deltas until the mouse ups happen. Listed below is code to make that happen.

var mouseMoves = from mm in mainCanvas.GetMouseMove()
                 let location = mm.EventArgs.GetPosition(mainCanvas)
                 select new { location.X, location.Y};
                 
var mouseDiffs = mouseMoves
    .Skip(1)
    .Zip(mouseMoves, (l, r) => new {X1 = l.X, Y1 = l.Y, X2 = r.X, Y2 = r.Y});

var mouseDrag = from _  in mainCanvas.GetMouseLeftButtonDown()
                from md in mouseDiffs.Until(
                    mainCanvas.GetMouseLeftButtonUp())
                select md;

The code should read rather straight forward as we attach to the mainCanvas object in order to draw. The interesting functions are the mouseDiffs and the mouseDrag. The mouseDiffs takes the mouseMoves and then skips 1 ahead and zips it with another mouseMoves, and projects to hold both left and right values. The mouseDrag function takes events from left mouse button down and then from mouseDiffs until the left mouse button up Observable happens.

Now that we have our mouseDrag, what can we do with it? Well, let’s go ahead and draw on our canvas:

var mouseSub = mouseDrag.Subscribe(item =>
{
    var line = new Line
                  {
                      Stroke = Brushes.LightSteelBlue,
                      X1 = item.X1,
                      X2 = item.X2,
                      Y1 = item.Y1,
                      Y2 = item.Y2,
                      StrokeThickness = 5
                  };
    mainCanvas.Children.Add(line);

Our mouseSub subscription creates a new line with our coordinates from zipped mouseDrag Observable and then adds it to our canvas. Consider how little code was required to make this happen, and try doing that with standard .NET events. Quite frankly, this kind of solution makes event-based programming using .NET events expressive enough to be usable.

Conclusion

[ANN] DC ALT.NET – 11/24/2009 “Stop Talking, Start Teaching” with Jeff Casimir

podwysocki — Tue, 10 Nov 2009 11:49:00 PST

As a group, we’ve been focusing a lot on technology on such things as JavaScript, MongoDB and so on. This month, I’d like to take a step back as a group and instead focus on some soft skills. When I started this group back in 2007, I had the idea that this group would help others not only become better technologists in a wide array of technologies, but also better teachers as well. On November 24th, we have Jeff Casimir to help us understand how to become a better teacher with his presentation “Stop Talking, Start Teaching: 5 Rules for Successful Presentations and Demos”. Listed below are the details:

Stop Talking, Start Teaching: 5 Rules for Successful Presentations & Demos

Some of the most important work we do as programmers involves pitching ideas. Whether it's inside the team, searching for funders, or running demos for potential clients, we all need to present ideas and cultivate an audience. The past decade has seen the rise of the presentation as an important communication medium, but few people do it well. There are many resources on how to make good looking slides, but we need to focus on the method, structure, and content.

We don't need to be "speakers" – we need to be teachers. In this session we'll explore the five most essential rules to successful teaching and how they apply to you.

Attendees will, by the end of the session, have a framework for designing and critiquing their work and that of others. This new understanding will make them better teammates and more successful salespeople.

About Jeff Casimir

After majoring in Computer Systems Engineering I joined Teach for America and began a career in education. I taught high school Computer Science for four years before moving into school administration. As a Vice Principal I was responsible for evaluating and hiring new teachers, observing and coaching existing teachers, and defining much of the school's academic process. Most of all, I hate boring presentations. I want these smart, experienced people to Stop Talking, and Start Teaching.

Hope to see you there!

Introduction to the Reactive Framework Part II

podwysocki — Mon, 02 Nov 2009 21:28:00 PST

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

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

podwysocki — Mon, 19 Oct 2009 16:01:00 PDT

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

podwysocki — Thu, 15 Oct 2009 20:40:00 PDT

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

podwysocki — Wed, 14 Oct 2009 22:47:00 PDT

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

podwysocki — Tue, 13 Oct 2009 22:31:00 PDT

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

podwysocki — Thu, 08 Oct 2009 21:39:00 PDT

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

podwysocki — Thu, 01 Oct 2009 22:27:00 PDT

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

podwysocki — Sun, 27 Sep 2009 19:47:00 PDT

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#

podwysocki — Fri, 25 Sep 2009 13:39:00 PDT

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

podwysocki — Tue, 15 Sep 2009 21:39:00 PDT

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.