Mark Dalgarno organised a fantastic one day conference in Cambridge last week – FPDay. To me, the day was a perfect mix of talks on functional programming together with 3 hours of hands-on time learning more about one of the three functional languages Haskell, Clojure and F#.
The day started with a keynote from Simon Peyton Jones who has devoted a large part of his career to researching functional programming ideas using the Haskell programming language. His talk was concerned with Haskell in the cloud, and was mainly concerned with adding Erlang like concurrency features to Haskell (as a new library). Erlang is interesting in that it embraces failure, with processes expected to simply die if they get into an error state from which they can’t recover. In order to implement this, processes are highly isolated, making the failure localised, and allowing the system as a whole to deal with the failure by having processes track the state of other processes. Isolation implies that objects are passed between the processes using object-by-value, and the talk covered how to get this working in a strongly typed languages. For most types of object, the typeclass mechanism of Haskell could be used to define serialize and deserialize functions that marshal the object into a ByteArray which could be passed across to the other process. The difficulty comes when you want to transfer a function between the two processes. In a functional language, the type of a function doesn’t describe the types of the objects that it might close over. A function is really described by the pair of an address (of the code) together with an environment that describes the closed over variables, and it is this representation, which makes all the parts of the function explicit, which could be marshalled across to the target process. The talk discussed how this new type of object could be expressed in Haskell – there’s sure to be a paper on this in the near future.
The second part of the day was a couple of 1.5 hour blocks where the attendees were divided into three streams, one for each of the functional languages listed above. I was lucky to go to the Haskell tutorial which was run by two people, Andres and Duncan, from well-typed. This was a great tutorial consisting of roughly an hour of slides on the Haskell language, followed by the rest of the time working through an example application of which the attendees had to implement various parts. This example consisted of defining an agent which would ask a set of yes/no questions to guess a number that the user had chosen. The example required the attendees to understand abstract data types, and moved on to use the QuickCheck framework built into GHCi to test their code. In the second part of the example, the Shed web server was downloaded using cabal and the game was turned into a stateful web based game. In this section, the state was saved into the URL using a embedded DSL describing the grammar for the state, which could be used both for the marshalling and unmarshalling.
Haskell is a mainly pure language though input and output via the IO monad complicates the issue. The tutorial didn’t have time to go into the IO monad in any detail, but there were some good discussions on IO and how it is specially built into the interpreter. IO has always confused me – it’s a monad, but the monad part is really about structuring the code. The strictness of the IO monad is really orthogonal to the use of the monad, and this was the first time that I’ve really put all of that together. There’s some good discussion in this blog post.
At the end of the tutorial there was a Haskell case study, where an energy company showed how they’d used Haskell to allow them to define various cost models which they could then simulate.
The final talk of the day was by Don Syme. It started with a great discussion of what made a language functional – having functions as first class objects is not really enough these days. Don had a set of 11 (I think) items that made a language functional, and I hope the slides get published at some point as this list was very good. The rest of his talk was about the new F# 3 type provider mechanism, a compiler extension that can be used by the system to dynamically define new F# types, and which can be used to do the kinds of things that we used to do by code generation. For example, taking an OData source and mapping it into the language.
The day was brilliant, with a load of like minded people enthusing about functional languages. I hope that it is repeated next year!