Lambda, Lambda, Lambda!

When I first heard about lambdas, I was highly skeptical primarily because I haven't seen or thought about these things since my computer science classes in college. If you need further evidence for my general skepticism, please see the definition of lambda expressions on Wikipedia. However, I was forced to look at them while researching the Linq project, so I decided to spend a bit more time with them and have a deeper look. And as it is with so many things, the more I surrounded myself with them, the more I kind of started to like them. Therefore, I'll spend a few seconds going over how I see them and you can use them.

At the core, a lambda expression is simply a function. You give it inputs, it gives you output. These expressions can then be linked together to build very complex programs. For the mind-numbing explanation, please see the Wikipedia article listed above. Anyways, in .NET terminology a lambda expression is a function that is fulfills the signature requirements specified by a delegate. For a little refresher, consider the following delegate that is defined in the .NET Framework 2.0.

public delegate bool Predicate<T> (T obj)

By the way, if you haven't gotten used to generics yet, I would start now as use of them is dramatically increased in the .NET Framework 3.5. Anyways, the predicate delegate is used by standard .NET collection classes to enable searching by arbitrary criteria. For example, let's say I define the class Person as follows.

public class Person { 
  public Person(string name, int age) { 
    Name = name; 
    Age = age; 
  } 

  public string Name; 
  public int Age; 
}

If I create a list of Person objects, I can filter that list to find all people with an age greater than 10 by creating an instance of the Predicate delegate and passing it to the FindAll method on my List class. The code would look as follows.

   1:  public static void Main() { 

   2:    List<Person> people = new List<Person>(); 

   3:    people.Add(new Person("howard", 29)); 

   4:    people.Add(new Person("jennifer", 30)); 

   5:    people.Add(new Person("hannah", 8)); 

   6:   

   7:    List<Person> oldPeople = people.FindAll(ageGT10Filter); 

   8:   

   9:    foreach (Person p in oldPeople) 

  10:      Console.WriteLine(p.Name); 

  11:  } 

  12:   

  13:  static bool ageGT10Filter(Person p) { 

  14:    return p.Age > 10; 

  15:  }

When the FindAll method is called (line 7), it iterates through my List object and calls my delegate instance (ageGT10Filter - line 13), passing it the Person object at that point in the list. If the delegate instance returns true, that Person object is added to the list returned by FindAll.

C# 2.0 extended this pattern of delegate passing with the introduction of anonymous methods (therefore, when looking at lambdas, I would expect that the concept will initially seem more familiar to C# developers as anonymous methods were not supported by VB.NET in VS 2005). By using anonymous methods, the code block above would look more like the following.

   1:  public static void Main() { 

   2:    List<Person> people = new List<Person>(); 

   3:    people.Add(new Person("howard", 29)); 

   4:    people.Add(new Person("jennifer", 30)); 

   5:    people.Add(new Person("hannah", 8)); 

   6:   

   7:    List<Person> oldPeople = people.FindAll(delegate(Person p) 

   8:      { return p.Age > 10; }

   9:    ); 

  10:   

  11:    foreach (Person p in oldPeople) 

  12:      Console.WriteLine(p.Name); 

  13:  }

As you can see, the delegate method instance is replaced by an inline method declaration (lines 7-9). This provides 2 major benefits to the previous approach: 1) fewer methods and smaller code, and 2) the constant declaration of 10 could be replaced with a user supplied value such as the following.

List<Person> oldPeople = people.FindAll(delegate(Person p) 
  { return p.Age > iValue; }); 

So now let's look at this implementation in C# 3.0 using lambda expressions.

List<Person> oldPeople = people.FindAll(p => p.Age > 10);

The first thing that I want to point out here is that the argument required by the FindAll method has not changed at all – it still requires a Predicate delegate instance. The lambda in this context is used as a shorthand way of defining the delegate instance. If we then look at the structure of the lambda expression itself, we'll see that it's really very simple.

Now, at this point, you're probably saying, "big deal – this is just a slightly shorter way to do something that I could already do in C# 2.0" – and if this was the only benefit that lambdas brought, you would be correct. However, there is something much, much cooler about lambdas in C# 3.0. This is that they can be treated as data and reinterpreted by other code (metaprogramming anyone?).

Rather than delve into an esoteric description, let's just see an example. Say that I wanted to be able to develop a generic query language – one that would be based on native C# code, but could be translated to all sorts of data sources, like SQL Server (starting to sound familiar??). For example, we would want our database query to look just like our previous in-memory query.

SQLEntityProvider.FindAll<Person>(p => p.Age > 10);

For the purposes of this example, we're going to assume a TON about the mapping relationship between the object and the database. Our generic provider might look something like the following.

   1:  public static IEnumerable<T> FindAll<T>(

   2:    Expression<Predicate<T>> filterExp) {

   3:   

   4:    StringBuilder sb = new StringBuilder(); 

   5:    sb.Append("select * from tbl" + typeof(T).Name); 

   6:    sb.Append(" where "); 

   7:   

   8:    BinaryExpression expBody = filterExp.Body as BinaryExpression; 

   9:   

  10:    if (expBody.Left.NodeType == ExpressionType.MemberAccess) 

  11:      sb.Append(((MemberExpression)expBody.Left).Member.Name); 

  12:   

  13:    switch (expBody.NodeType) { 

  14:      case ExpressionType.GreaterThan: 

  15:        sb.Append(" > "); 

  16:        break; 

  17:      case ExpressionType.LessThan: 

  18:        sb.Append(" < "); 

  19:        break; 

  20:      case ExpressionType.Equal: 

  21:        sb.Append(" = "); 

  22:        break; 

  23:      case ExpressionType.NotEqual: 

  24:        sb.Append(" <> "); 

  25:        break; 

  26:    } 

  27:   

  28:    if (expBody.Right.NodeType == ExpressionType.Constant) 

  29:      sb.Append(((ConstantExpression)expBody.Right).Value); 

  30:   

  31:    Console.WriteLine(sb.ToString()); 

  32:   

  33:    return null; 

  34:  }

When the program is run and we examine the console output, we see the following.

select * from tblPerson where Age > 10

Now when you step back and think about it, this is actually REALLY cool – and what enables this coolness is the fact that lambda expressions, in addition to being directly executable, can also be treated as data. This is what enabled me to look through the expression tree and convert the lambda expression elements into equivalent SQL statement elements. So how do you control whether your lambda expression is treated as code (delegate) or as data? Simple – either pass it to a parameter expecting a delegate instance (as in my first case) OR pass it to a parameter expecting a object of type Expression<TDelegate>. The Expression generic type has special meaning in C# 3.0 and parses the lambda expression into a data structure rather than generating IL executable code.

So now that you have a general idea of how this new language feature works, what can you do with it? As is always the case – whatever you want! Personally, I would love to see somebody write an extension to NHibernate to allow use of Linq queries in the place of HQL – so if anyone's looking down that path, please let me know! However, even if you're not running to the bleeding edge to start implementing your own lambda based solutions, I hope that this article has given you just a bit of insight into how Linq works, and how we are just scratching the surface on what we can do with this powerful new language feature!