F# in Education & Concurrency with Agents

November was quite a busy month for me. First, I traveled to Cambridge (the "new one" in Massachusetts :-)) to present my work on the F# plugin for MonoDevelop at the F# in Education workshop. Shortly after getting back to London, I started working on a presentation about Concurrent Programming with Agents at the F#unctional Londoners meeting.

Now that both of the events are over, I'd like to write a short summary and also finally publish my slides and demos. In addition, both of the events were recorded (thanks to External Research group at MSR and SkillsMatter), so if you missed them, you can watch the recording...

Both of the events were really great and I had a chance to meet quite a few interesting people. One of the things that make F# great is the community around it. I think that one unique aspect of the F# community is its diversity. The same language is appealing to high school teachers, academics and researchers as well as software developers and technical directors from the industry. This combination is really valuable for both sides. It helps to transfer ideas from research to practice it gives researchers clear picture of problems in the industry that deserve their attention.

Concurrent programming with F# agents in London

If you live anywhere near London and are interested in F#, then you probably already follow the F#unctional Londoners group started by Carolyn Miller and Phil Trelford. I gave a talk at the user group in June about Reactive programming in F# (if you missed that, you can view the recording). I really enjoyed talking to an audience where most of the people already played with F#, so when I met with Phil recently, I couldn't resist offering another presentation.

My next talk will be about Concurrent programming with Agents using the MailboxProcessor type. A part of the talk will be inspired by my recent blog series about parallel programming, but I just finished another pretty cool example, so you should come even if you read my blog! This time, we'll have two talks, so you can also look forward to Phil Trelford's Behaviour Driven Development with TickSpec (you just cannot miss his debugging demo!).

When, what & where?

• See also: Concurrency with Agents and BDD with TickSpec at F#unctional Londoners
• Date & time: 24 November (Wednesday), 7:00 PM
• Location: The Skills Matter eXchange, 116-120 Goswell Road, London

Last time, I brought a copy of my Real-World Functional Programming as a giveaway and I think I still have a few copies lying around...

Talk teaser: F# agents

F# agents (the MailboxProcessor type) are an implementation of message passing concurrency. This is a very attractive alternative to shared memory or even standard task-based or data-parallel concurrency models. It makes it easy to write reactive applications that receive inputs from various sources in parallel (e.g. user interface, network, background tasks etc.) Agents communicate by sending (immutable) messages to each other, which makes the application easy to understand. If you design the application correctly (and structure it using enough agents) it can be also very scalable. Among other things, I'll show the following examples:

• Agent-based chat - A simple example to introduce agents will be a chat room that uses agent to store the state of a chat. You'll see that an asynchronous and concurrent application can be written quite easily with F#. You'll also see how to expose this service using a few lines of beautiful F# code inspired by Node.js.
• Reusable agents, buffering and blocking - We'll also look at a few agents that are not directly bound to any application and you can use them to implement common communication patterns. If you have a few agents like this, you can easily put together a sophisticated application just by composing existing agents.

Asynchronous C# and F# (III.): How does it work?

Some time ago, I started writing a series about the differences between the asynchronous model in F# (in Visual Studio 2010) and the asynchronous language extensions for C# proposed at PDC 2010. In the first article, I showed how both of the language features look and I highlighted a couple of differences. In the second article, I discussed the support for cancellation (available only in F#) and how the two models differ semantically (i.e. what are differences in the behaviour). However, I didn't talk about more techincal differences and, in particular, how is the asynchronous code compiled. We'll look at this topic today...

Although the C# asynchronous programming model is very similar to F# asynchronous workflows, the compilation looks quite different. The C# compiler uses a similar technique as when compiling iterators and creates a state machine, while the F# compiler uses an approach based on higher order functions (combinators) that's shared with (most) other computation expressions.

I won't discuss the syntax of F# asynchronous workflows or the C# asynchronous extensions in this article, so if you're new to one of these, here are links to other articles in this series:

• Asynchronous C# and F# (I.): Simultaneous introduction
• Asynchronous C# and F# (II.): How do they differ?
• Asynchronous C# and F# (III.): How does it work?
• Asynchronous C# and F# (IV.): Calling F# libraries from C# (not yet available)

Let's start by looking at the mechanism used in the C# compiler. If you already know how iterators work in C# 2.0, then you'll find it quite easy to understand. If you're not familiar with iterators, then don't worry - I'll make the explanation self-contained.

F# community on GitHub & MonoDevelop update

When I talked with Miguel de Icaza and Michael Hutchinson at the F# in Education workshop some time ago, someone mentioned that it would be nice to have a clone of the official F# code drop that could accept patches from the community. I also talked with Michael about GitHub and I think I finally understood why everybody uses it today. I said to myself that I'll need to take a look at it when I'll have a bit of time... After coming back from the workshop, I was quite busy getting the F# plugin for MonoDevelop out, but after I wrote about it, I finally found some time to look at GitHub.

I really like the way Mono team uses GitHub. They have a single "mono" organization that is owned by several people from the Mono community and all important projects that are parts of Mono have their repository as part of the "mono" organization. Thanks to GitHub, everyone can easily clone the repository, do some changes and submit a "pull request" to the main repository.

I thought that the F# community could follow the same model, so I started the F# community organization on GitHub...

F# in MonoDevelop and cross-platform web sites & screencasts

About a week ago, I attended the F# in Education workshop in Boston. It was a great event with many interesting people around. I believe that the workshop was very exciting for everyone who is interested in F#, but uses Mac or Linux. The F# team recently made some effort to improve the F# support on Mono (meaning mainly Mac and Linux). The recent November 2010 CTP update contains several bugfixes that make it possible to use F# on Mono 2.8. Another great thing that happened at the workshop is the open source release of F# (see also blog post by Miguel with a post-check-in photo). At the workshop, I also announced my contribution to the cross-platform F# story, a project that I've been working on recently - the F# language binding for MonoDevelop.

Click here for a larger screenshot

I promised to make it available as soon as possible after the workshop. As usually, things take longer, than one would like, but I'm finally ready to announce the initial (beta) version of the plugin. The screenshot on the right shows some of the features of the F# language binding. As you can see, there is an F# Interactive tool window, syntax highlighting as well as IntelliSense auto-completion.

If you're interested in trying it out, here are links to the repository (you can use it to install the language binding from the MonoDevelop Add-ins manager) and source code. The F# plugin needs to be able to locate F# installation and it also requires more F# assemblies to be installed in the GAC, so you may as well want to read the instructions before trying it :-).

• Project homepage at the Functional Variations web site has more information about the project as well as detailed installation instructions.
• I also created a web page that contains information about installing F# on Mac and Linux which explains how to install F#, such that the MonoDevelop plugin can find it.
• The source code is available in the F# cross-platform packages and samples project at CodePlex (under the Apache 2.0 license). You can find it in the monodevelop subdirectory.
• Online repositiory with a MonoDevelop package is available at: http://functional-variations.net/addin.
  (If you're a hacker, the easiest way to get it working is to add FSharp.Compiler* to GAC and set FSHARP_COMPILER_BIN environment variable to F# installation location)

If you want to see some interesting uses of the F# MonoDevelop plugin, you can also watch my talk at the F# in Education event. In one demo, I used F# on Mac to play with a simple, composable functional 3D library. In another example I demonstrated how to asynchronously process stock prices on Linux. The last demo, showing my match! extension didn't work all that well, because I had too many virtual machines running, but I'll blog about match! again sooner or later!

In addition to the F# plugin for MonoDevelop itself, I'd also like to mention two web sites that I've been working on and some interesting cross-platform F# screencasts...

Asynchronous C# and F# (II.): How do they differ?

Anders Hejlsberg announced the support for asynchronous programming in the next version of C# announced at PDC 2010. The extension looks very similar to F# asynchronous workflows (which are already available in Visual Studio 2010). Despite the large similarity, there are a couple of differences between the two programming models. I already mentioned some of them briefly in the first article of this series. In this article, we'll look at some of the technical differences between the two models.

The most notable non-technical difference is that F# asynchronous workflows are already available in a supported version of Visual Studio and can be used on a large number of .NET runtimes (including, for example, Windows Phone and Silverlight). However, there are surprisingly many technical differences as well. In this article, I'll talk about the support for cancellation, which is available in F# and is not (currently) available in the C# preview. We'll also look at the difference between model where tasks are created as running and the delayed model.

This article is the second part of a short series about the asynchronous programming support in C# and F#. The previous article shows a simple example in both of the languages and the next articles explain how does the feature work (and how you can customize its behavior) as well as how to call F# libraries from C#:

• Asynchronous C# and F# (I.): Simultaneous introduction
• Asynchronous C# and F# (II.): How do they differ?
• Asynchronous C# and F# (III.): How does it work?
• Asynchronous C# and F# (IV.): Calling F# libraries from C# (not yet available)

Let's start by looking at, perhaps, the most important technical difference - the built-in support for cancellation available in F# asynchronous workflows.

All blog posts by tag