Mathematical duality  is a very useful and elegant concept that gives us a nice way of speaking about objects or structures that behave in some way exactly conversely. There is no clear definition of what duality is. However, the idea is that when we have two structures that behave conversely and we know that something is true about the first one, then we get the opposite statement about the other structure "for free" (if you know how to translate from one structure to the other).
In this article, I'll talk about an interesting example of duality that (to my best knowledge) wasn't described by anyone before. The two dual structures are references between objects in a normal program and references between events in a reactive application. The statement that is going to become obvious thanks to the duality principle is describing which of the objects (or events) are garbage and can be safely collected by garbage collector.
This topic is in much more details discussed in a paper  I wrote with Don Syme and that I presented at the ISMM Workshop (see also my trip report from PLDI). In this article, I'll try to give an accessible description of the most interesting idea from the paper...
When reading data from a SQL database in F#, you have a couple of options.
You can use F# implementation of LINQ, which allows you to write queries directly
in the F# language or you can use standard ADO.NET classes such as
The second option is often good enough - when you just need to call a simple
query, you probably don't want to setup the whole LINQ infrastructure (generate
classes, reference F# PowerPack, etc.) Unfortunately, ADO.NET classes are a bit
ugly to use. When calling an SQL stored procedure, you need to specify the name
of the procedure as a string, you need to add parameters one-by-one by creating
SqlParameter, you need to dynamically cast results from
obj type and so on...
In this article, we'll look how to use the dynamic operator to make the experience of using ADO.NET from F# dramatically better. Dynamic operator (there are actually two of them) are a simple way of supporting dynamic invoke in F#. We can use it to write code that looks almost like an ordinary method call or property access, but is resolved dynamically at runtime (using the name of the method or property). The following example shows what we'll be able to write at the end of this article:
// Call 'GetProducts' procedure with 'CategoryID' set to 1 use conn = new DynamicSqlConnection(connectionString) use cmd = conn?GetProducts cmd?CategoryID <- 1 conn.Open() // Read all products and print their names use reader = cmd.ExecuteReader() while reader.Read() do printfn "Product: %s" reader?ProductName
If you ever tried to call a SQL stored procedure directly using the
SqlCommand, then you can surely appreciate the elegance of this code
snippet. Let's now take a look at a larger example and some of the neat
tricks that make this possible...
In June, I attended my first "big" academic conference Programming Languages Design and Implementation (PLDI 2010) in Toronto. I attended the conference, because I presented a paper that I wrote with Don Syme as a result of my internship at Microsoft Research, but I'll write more about that shortly (and thanks to MSR for partly supporting my attendance at the conference!)
As far as I understand it, the focus of the conference is more on implementation. Many people believe that the current programming languages are good enough and we need to make sure that they run well (e.g. compilers optimize code to run better on multi-core) and that we need better tools for working with them (e.g. automatic verification of the code we write), so these areas were the main focus of the conference. However, there were some very interesting talks on the design of programming languages, which is an area that I personally find more interesting...