Tomas Petricek

Searching for new ways of thinking in programming & working with data

I believe that the most interesting work is not the one solving hard problems, but the one changing how we think about the world. I follow this belief in my work on data science tools, functional programming and F# teaching, in my programming languages research and I try to understand it through philosophy of science.

The Gamma

I'm working on making data-driven storytelling easier, more open and reproducible at the Alan Turing Institute.

Consulting

I'm author of definitive F# books and open-source libraries. I offer my F# training and consulting services as part of fsharpWorks.

Academic

I published papers about theory of context-aware programming languages, type providers, but also philosophy of science.

Tomas Petricek
  • Tomas Petricek
  • Home
  • F# Trainings
  • Talks and books
  • The Gamma
  • Academic

Reactive programming (I.) - First class events in F#

I believe that the LINQ project and changes in C# 3.0 and VB 9 are interesting because they allow rewriting of many ideas from functional programming. An ability to express queries easily is one of these ideas, but it is definitely not the only one. There are many other interesting ideas. The C# 3.0 language isn't primary a functional language, so it isn't easy to discover the idea if you use only C#, but it is possible to implement it if you know the idea already.

I already wrote a few interesting C# examples that were inspired by some functional idea. I'm a big fan of the F# language, so it is not a surprise that I started with an F# version of the problem and then looked at the way to do the same thing in C#. In particular, this is how my article about building dynamic queries in C# came to the existence - the F# version used FLINQ and Quotations [2] and then I demonstrated how to do the same in C# using expression trees [3]. Another example is my article about asynchronous programming in C# using iterators [4], which shows how to implement something like F# asynchronous workflows [5] using iterators in C# 2.0.

Functional Reactive Programming

Today, I'm going to look at another very interesting idea from functional programming. It is called Functional Reactive Programming and it comes from the Haskell community. You can find a list of related Haskell projects here. However, similar things (though they are not purely functional and somewhat simplified) are available in the F# language as well. Don Syme introduced them in his blog post called "F# First Class Events: Simplicity and Compositionality in Imperative Reactive Programming" [1]. In this article, I'm going to briefly introduce the implementation available in F# and I'll extend it a little bit to allow some more interesting things. In the second article from this series, I'll show how to implement the same thing in C# 3.0 (and in VB 9 too!)

Actually this relation between functional programming in F# and C# is the key topic for my book Real-world Functional Programming in .NET. The book will discuss some of the topics that I'll introduce in this article in a larger detail. In this article I'll talk about events only, but the second important part of functional reactive programming is the use of continuous, time-varying values (such as the position of mouse or the time). In the book, this will be discussed as part of the Chapter 15 and events are the key topic for Chapter 16.

Working with events in F#

Form with an ellipse

Let's briefly look at the features that are already available in the F# language and libraries. In F#, you can work with events as if they were ordinary objects (in functional terminology, we'd say values). This means that you can write a function that takes an event as an argument and returns an event. This allows us to write various functions for processing events. We'll demonstrate this soon, but first let's create some form that we can use for testing. The following example shows how to create a Windows Form with a small green ellipse somewhere on the form. You can see the expected result in the attached screenshot. If you paste the source code to the F# interactive, a form should appear (Note, you can open the code in Visual Studio, select it and hit Alt + Enter to run it in the F# interactive):

#light
open System.Drawing
open System.Windows.Forms

// Generate random location for the ellipse
let rnd = new System.Random()
let x, y = rnd.Next(550), rnd.Next(350)

// Create the main form
let frm = new Form(ClientSize=Size(600,400))
// Add event handler to paint the ellipse
frm.Paint.Add(fun e ->
    e.Graphics.FillRectangle(Brushes.White, 0, 0, 600, 400)
    e.Graphics.FillEllipse(Brushes.DarkOliveGreen, x, y, 50, 50)  
  )
frm.Show()

Nothing very exciting so far; n this example we used events in the traditional way. This means that we used the Add method to attach a handler to the event and we specified the event handler in a lambda function (which is just like anonymous delegate in C# 2.0 or function in C# 3.0). This is the usual way for attaching handlers to events in C# too, with the difference that you use built-in += operator.

Processing event streams

Now, let's finally take a look at the F# way of processing events. We'll extend the example to display some message when a user clicks on the ellipse. Traditionally, you'd write an event handler that would get MouseEventArgs as an argument. It would test whether the position of the cursor is inside the ellipse and then show the message. However, there is another way we can think about events. You can imagine that event such as MouseDown is a stream of information about the clicks. Once you click on the form, new information appears in the stream and we can process it. When we think of events in this way, we can see that events (or event streams) are very similar to lists or other collections. This means that we can use techniques for working with collections for processing events.

I already wrote about functions for working with lists in F# in my F# overview [6], but very briefly - you can use functions like filter and map for working with lists. The first one returns a list with elements for which a given predicate is true. The second one uses the given function to transform an element (for example a number n) into something else (for example a type that contains the original number and its square). Let's take a look at an example that demonstrates this:

> [1 .. 10]
    |> List.filter (fun n -> n % 2 = 1)
    |> List.map (fun n -> (n, n*n));;
val it : (int * int) list = [(1, 1); (3, 9); (5, 25); (7, 49); (9, 81)]

In this example, we took a list of numbers from 1 to 10. Then we filtered it using List.filter, so the result contained only odd numbers. Finally, we used the List.map function to transform the list into a list that contains a number and its square. We're using the pipeline operator (written as |>) to sequence the operations. This simply means that the result of the operation on the left side will be used as an argument for the next operation in the pipeline. You can see that the result printed by the F# interactive contains squares of all odd numbers in that range.

You may be wondering why I am talking about lists here, when I promised an article about events. The answer is that functions like this make perfect sense for working with events as well. We can use filter to ignore events that are not interesting for us (such as when the user clicks outside of the ellipse) and we can use map to turn information about the click into something more interesting, such as a message that we'll show to the user. Let's finally implement the code that handles clicks on the ellipse using these event processing functions:

> // Utility function to calculate the distance 
  open System
  let dist (x1, y1) (x2, y2) =
    Math.Sqrt(Math.Pow(x1 - x2, 2.0) + Math.Pow(y1 - y2, 2.0))
  ;;
val dist : float * float -> float * float -> float

> let evtMessages =
    frm.MouseDown
      |> Event.filter (fun mi -> 
          // The distance between click location and 
          // the center of the ellipse is less than 25
          dist (float mi.X, float mi.Y) (float(x + 25), float(y + 25)) < 25.0 )
      |> Event.map (fun mi ->
          // Return message that we'll show to the user
          if (int (mi.Button &&& MouseButtons.Left) <> 0) then "Left button"
          elif (int (mi.Button &&& MouseButtons.Right) <> 0) then "Right button"
          else "Some trick!")
  ;;
val evtMessages : IEvent<string>

We aren't yet done with the application, but we did two important steps. Let's take a look at them in detail. We first used the Event.filter processing function. The predicate that we gave it tests whether the center of the ellipse (x + 25, y + 25) is close enough to the location of the mouse click. The mi value represents MouseEventArgs, so the location of the click is stored in (mi.X, mi.Y). The next processing function we're using is Event.map. This takes the information about the click and returns some string depending on the button that was used.

Clicked on the ellipse

I entered the code to the F# interactive, so that we can see what the result is. As you can see, this creates a value called evtMessages that has a type IEvent<string>. This is the F# representation of events. This means that the result is an event that will be raised when the user clicks on the ellipse. The values carried by the event will be of type string. The only thing that we need to do now is to add handler for the event and display the message in the message box. Our goal is to get something like the message in the screenshot on the right side.

Reacting to events

The evtMessages value is an ordinary event, so we could use its Add method just like we used Add method of the frm.Paint event earlier. However, F# gives us more ways to do this and it's a good idea to use the same approach that we used in the previous listing to filter the event stream.

We need to do two things - first, we'll need to add some additional text to the message and second, we want to display the message box. This can be written using two primitives. You know the first one already - we'll use Event.map to turn the event stream with simple messages into a stream that contains messages that we actually want to show to the user. In the next step, we'll use Event.listen. This is a processing function that simply calls a function we give it when the event is raised and doesn't do anything else. This means that it ends our event processing code and returns unit, which is just like void in C#. We'll use two more functional tricks - partial function application and function composition. These are in detail explained in my F# book, but you can get some idea from the F# overview [5] that I wrote some time ago.

evtMessages
  |> Event.map (sprintf "Hey, you clicked on the ellipse.\nUsing: %s")
  |> Event.listen (MessageBox.Show >> ignore)

This time we'll writing processing code for the evtMessages value, which is an event that we constructed in the previous example. In the first line, we use the Event.map function to format the message. We use the sprintf function and give it a format string that specifies that the function should expect a string as an argument. This means that the type of the expression in parentheses will be a function that takes a string and returns a string. This is compatible with what Event.map expects - it is a function. We used partial application, which means that we omitted the last argument and used the expression as a function value.

The second line uses Event.listen to show the message box. As other functions for processing events, this one also expects a function as an argument. The function will get string as an argument and shouldn't return anything, because Event.listen terminates the event processing. In the example, we use function composition operator (>>) to create a function that will take a string, call MessageBox.Show and then ignore the value returned by the MessageBox.Show (we have to add ignore, because MessageBox.Show returns a DialogResult and Event.listen expects that nothing will be returned).

Summary

In this article, we've looked at an example that demonstrates the idea behind reactive programming and working with events as values in F#. I haven't discussed all the details - there are many other operations such as Event.map and Event.filter that you can use to combine event processing code in different ways (and these are indeed discussed in my book). In the next part of this mini-series, we're going to look how to implement the same ideas in C#. I'll also introduce my project, which is an implementation of LINQ query operators for events that I call Reactive LINQ.

  • Download the examples (1.10kB)

Series links

  • Reactive programming (I.) - First class events in F#
  • Reactive programming (II.) - Introducing Reactive LINQ
  • Reactive Programming (III.) - Useful Reactive LINQ Operators
  • Reactive Programming (IV.) - Developing reactive game in Reactive LINQ

References

  • [1] F# First Class Events: Simplicity and Compositionality in Imperative Reactive Programming - Don Syme's WebLog on the F# Language and Related Topics
  • [2] Building LINQ Queries at Runtime in F# - TomasP.Net
  • [3] Building LINQ Queries at Runtime in C# - TomasP.Net
  • [4] Asynchronous Programming in C# using Iterators - TomasP.Net
  • [5] Introducing F# Asynchronous Workflows - Don Syme's WebLog on the F# Language and Related Topics
  • [6] F# Overview (II.) - Functional programming - TomasP.Net

Published: Sunday, 16 November 2008, 5:14 PM
Author: Tomas Petricek
Typos: Send me a pull request!
Tags: functional, c#, asynchronous, meta-programming, f#

Contact & about

This site is hosted on GitHub and is generated using F# Formatting and DotLiquid. For more info, see the website source on GitHub.

Please submit issues & corrections on GitHub. Use pull requests for minor corrections only.

  • Twitter: @tomaspetricek
  • GitHub: @tpetricek
  • Email me: tomas@tomasp.net

Blog archives

October 2020 (1),  July 2020 (1),  April 2020 (2),  December 2019 (1),  February 2019 (1),  November 2018 (1),  October 2018 (1),  May 2018 (1),  September 2017 (1),  June 2017 (1),  April 2017 (1),  March 2017 (2),  January 2017 (1),  October 2016 (1),  September 2016 (2),  August 2016 (1),  July 2016 (1),  May 2016 (2),  April 2016 (1),  December 2015 (2),  November 2015 (1),  September 2015 (3),  July 2015 (1),  June 2015 (1),  May 2015 (2),  April 2015 (3),  March 2015 (2),  February 2015 (1),  January 2015 (2),  December 2014 (1),  May 2014 (3),  April 2014 (2),  March 2014 (1),  January 2014 (2),  December 2013 (1),  November 2013 (1),  October 2013 (1),  September 2013 (1),  August 2013 (2),  May 2013 (1),  April 2013 (1),  March 2013 (1),  February 2013 (1),  January 2013 (1),  December 2012 (2),  October 2012 (1),  August 2012 (3),  June 2012 (2),  April 2012 (1),  March 2012 (4),  February 2012 (5),  January 2012 (2),  November 2011 (5),  August 2011 (3),  July 2011 (2),  June 2011 (2),  May 2011 (2),  March 2011 (4),  December 2010 (1),  November 2010 (6),  October 2010 (6),  September 2010 (4),  July 2010 (3),  June 2010 (2),  May 2010 (1),  February 2010 (2),  January 2010 (3),  December 2009 (3),  July 2009 (1),  June 2009 (3),  May 2009 (2),  April 2009 (1),  March 2009 (2),  February 2009 (1),  December 2008 (1),  November 2008 (5),  October 2008 (1),  September 2008 (1),  June 2008 (1),  March 2008 (3),  February 2008 (1),  December 2007 (2),  November 2007 (6),  October 2007 (1),  September 2007 (1),  August 2007 (1),  July 2007 (2),  April 2007 (2),  March 2007 (2),  February 2007 (3),  January 2007 (2),  November 2006 (1),  October 2006 (3),  August 2006 (2),  July 2006 (1),  June 2006 (3),  May 2006 (2),  April 2006 (2),  December 2005 (1),  July 2005 (4),  June 2005 (5),  May 2005 (1),  April 2005 (3),  March 2005 (3),  January 2005 (1),  December 2004 (3),  November 2004 (2), 

License

Unless explicitly mentioned, all articles on this site are licensed under Creative Commons Attribution Share Alike. All source code samples are licensed under the MIT License.

CC License logo