Translating lambda expressions

They're the new black of programming languages - lambda expressions - a powerful construct, used & abused to ultimately produce more readable code. I find myself using them most when taking advantage of the Linq libraries.

A naive example In C#:

[sourcecode language="csharp"]
public IQueryable GetActiveUsers() {
return AllUsers.Where((user) => user.IsActive; );
}
[/sourcecode]

In VB .NET:

[sourcecode language="vb"]
Public Function GetActiveUsers() as IQueryable(Of User)
Return AllUsers.Where(Function (user) user.IsActive )
End Function
[/sourcecode]

In F#:

[sourcecode language="fsharp"]
member self.GetActiveUsers =
AllUsers |> List.filter (fun user -> user.IsActive)
[/sourcecode]

Though lately, there are more cases where lambdas are used to simplify an API that I might be using. Lambdas make for declarative code, describing what you want, not how you want it done. The canonical example is surely the trend away from the record/replay model in mocking frameworks of late:

[sourcecode language="csharp"]
[Test]
public void it_should_launch_nuclear_missles()
{
IMissleLauncher launcher = new Mock();
DoomsdayDevice dd = new DoomsdayDevice(launcher.Object);
dd.ActivateWithMessage("BROUAHAH");

launcher.Verify(l => l.Launch(Missles.Nuclear));
}
[/sourcecode]

Generally, this type of API uses the syntax tree generated for the lambda expression, to determine the consumers intent, in order to translate that intent to some other function. In the Linq 2 SQL case, the tree is turned into SQL statements.

But not all .NET languages are created equally in the functional programming department, especially when it comes to building expression trees from these pieces of syntactic sugar. VB and C# can interchange them naturally - since they both use the System.Linq.Expressions namespace.

In F#, lambda expressions can also be interpreted via expression trees, using the Quotations namespace. While there is some overlap between the two namespaces, the focus is in different areas.

Right now what this means for multilanguage solutions is that an F# application cannot directly use its lambda function syntax to satisfy C# functions that use expressions. Unfortunately, this puts F# very much at odds with libraries in other .NET languages. More and more, we are seeing clever use of expressions to aid API developers in providing intuitive interfaces, and fiddling about with translating lambda expressions is the last thing a developer really wants to do when consuming an API, presumably to solve some other problem.

However all is not lost, hidden away in the Powerpacks are some experimental functions that allows us to attempt translation in both directions. For those instances where we aren't stretching the boundaries of C#, we can convert F# functions into expressions with the following:

[sourcecode language="fsharp"]
open Microsoft.FSharp.Linq.QuotationEvaluation ;;
open System ;;
let q = <@ fun x -> x = 0 @> ;;
let expr = q.ToLinqExpression() ;;
[/sourcecode]

The powerpack provides a swag of extensions to the FSharp.Core.FuncConvert class in order to allow two way translation between F# and other languages that favour delegates.

From here we can drill into our expression to return more useful variations if required from our C# library. There are a tonne of ways to skin this cat; here in this simplistic example I use an active pattern matching to match expression types.

let toLinqExpression (q:Expr<'a->'b>) =
let expr = q.ToLinqExpression()
let rec convert ex =
match ex with
| MethodCall (args) ->
convert args.[0]
| Lambda (body, parameters) ->
Expression.Lambda<func<'a, 'b>>(body, parameters)
| Unknown -> raise(new NotSupportedException())
convert expr
[/sourcecode]