Lambda Expressions: C# has a Lisp??


Until I started looking at C# 3.0, I had never heard of lambda expressions.  A quick glance at Wikipedia tells me that they seem to pre-date computers, and languages like Lisp and Ruby seem to be based on them. But what the heck are lambda expressions??  The short answer is: They are just shorthand anonymous methods.


It took me a little while to get my head wrapped around they syntax (especially the “classical” syntax on wikipedia), but now I get it!!  In the simplest possible example, here is a function which adds one to the parameter:


Func<int, int> increment = A => A + 1;
Console.WriteLine(increment(5)); // outputs 6


Basically, we are defining a function “increment” as its parameter A, plus one.  Ok, that’s not so bad, and I know a lot of places I could use a quick little function definition to parse some input or test some conditions.  Given that, I thought I would try something a little harder … factorial.


Now with factorial, I ran into some immediate problems.  I don’t think that lambda expressions are designed to be recursive.  I couldn’t find an equivalent to “this” for the expression, and if I reference the function itself, I get an error telling me that I am using an undefined variable.  After some tinkering, I found a way around this.  Lambda expressions can be passed as parameters to other lambda expressions.  So what if I just passed my factorial expression a reference to itself.


Func<long, object, long> f = (A, B) => A == 0 ? 1 : (A*((Func<long,object,long>)B)(A-1,B));
Func<long, long
> factorial = A => f(A, f);


Console.WriteLine(factorial(25).ToString(“#,###”));
// outputs 7,034,535,277,573,963,776


And so that’s what I did.  I had to pass the function reference as an object because I could not really specify its type.  f’s definition would look like this if I tried:


Func<long, Func<long, Func<long, … and so on … , long>, long>, long>


The “f” expression does the real factorial work, “factorial” just gets the first iteration going.  Are lambda expressions going to change the way we program??  I don’t know.  What do you think?


Lisp and similar languages (which are) seem to be making a comeback, and I had no clue that Orbitz.com is written in Lisp until I read it on wikipedia.  I don’t really know anything about Lisp, but it got me thinking that maybe Lisp could be a first class .NET language now that lambda expressions will be baked into the CLR 3.0.  I’ll have to look into this further.


Comments (6)

  1. RGabo says:

    Lambda expressions are a C# 3.0 language feature, not a CLR feature. Look at the IL that gets generated.

    There will be no CLR upgrade needed when C# 3.0 / LINQ comes out!

  2. Colin says:

    If code readability is the goal for lambda expressions, I’d actually prefer the old way for all but the simplest expressions (I mean simple like the first example you gave).

    Just because new code fits on a single line doesn’t make it more readable. Indeed, you could remove the carriage returns for every class file to fit pages of code onto a few lines, but that would be a nightmare to decipher!

    Lambda expressions have a similar readability problem in my opinion, albeit to a lesser degree.

    You ask "Are lambda expressions going to change the way we program?" and I say "I hope the heck not!" Granted they have their place, but I think Microsoft is setting the language up for a lot of programmers to write unreadable code!

  3. brianbec says:

    public delegate long dg(long l, dg gee);

    dg g = (long A, dg B) => A == 0 ? 1 : (A * B(A – 1, B));