Lambda for Dummies....anyone, anyone? I think not_问答_开发者

In my quest to understand the very odd looking ' => ' operator, I have found a good place to start, and the author is very concise and clear:

parameters => expression

Does anyone have any tips on understanding the basics of lambdas so that it becomes easier to 'decipher' the more complex lambda statements?

For instance: if I am given something like (from an answer 开发者_JS百科I received here):

filenames.SelectMany(f => 
        Assembly.LoadFrom(f).GetCustomAttributes(typeof(PluginClassAttribute), true)
        .Cast<PluginClassAttribute>()
        .Select(a => a.PluginType)
).ToList();

How can I go about breaking this down into more simple pieces?

UPDATE: wanted to show off my first lambda expression. Don't laugh at me, but I did it without copying someone's example...and it worked the first time:

public ModuleData[] GetStartModules( )
{ return modules.FindAll(start => start.IsBatch == true).ToArray(); }

Let's dissect your code sample:

filenames.SelectMany(f => 
        Assembly.LoadFrom(f).GetCustomAttributes(typeof(PluginClassAttribute), true)
        .Cast<PluginClassAttribute>()
        .Select(a => a.PluginType)
).ToList();

So, we start off with a string[] called filenames. We invoke the SelectMany extension method on the array, and then we invoke ToList on the result:

filenames.SelectMany(
   ...
).ToList();

SelectMany takes a delegate as parameter, in this case the delegate must take one parameter of the type string as input, and return an IEnumerable<T> (Where the type of T is inferred). This is where lambdas enter the stage:

filenames.SelectMany(f => 
        Assembly.LoadFrom(f).GetCustomAttributes(typeof(PluginClassAttribute), true)
).ToList()

What will happen here is that for each element in the filenames array, the delegate will be invoked. f is the input parameter, and whatever comes to the right of => is the method body that the delegate refers to. In this case, Assembly.LoadFrom will be invoked for filename in the array, passing he filename into the LoadFrom method using the f argument. On the AssemblyInstance that is returned, GetCustomAttributes(typeof(PluginClassAttribute), true) will be invoked, which returns an array of Attribute instances. So the compiler can not infer that the type of T mentioned earlier is Assembly.

On the IEnumerable<Attribute> that is returned, Cast<PluginClassAttribute>() will be invoked, returning an IEnumerable<PluginClassAttribute>.

So now we have an IEnumerable<PluginClassAttribute>, and we invoke Select on it. The Select method is similar to SelectMany, but returns a single instance of type T (which is inferred by the compiler) instead of an IEnumerable<T>. The setup is identical; for each element in the IEnumerable<PluginClassAttribute> it will invoke the defined delegate, passing the current element value into it:

.Select(a => a.PluginType)

Again, a is the input parameter, a.PluginType is the method body. So, for each PluginClassAttribute instance in the list, it will return the value of the PluginType property (I will assume this property is of the type Type).

Executive Summary
If we glue those bits and pieces together:

// process all strings in the filenames array
filenames.SelectMany(f => 
        // get all Attributes of the type PluginClassAttribute from the assembly
        // with the given file name
        Assembly.LoadFrom(f).GetCustomAttributes(typeof(PluginClassAttribute), true)
        // cast the returned instances to PluginClassAttribute
        .Cast<PluginClassAttribute>()
        // return the PluginType property from each PluginClassAttribute instance
        .Select(a => a.PluginType)
).ToList();

Lambdas vs. Delegates
Let's finish this off by comparing lambdas to delegates. Take the following list:

List<string> strings = new List<string> { "one", "two", "three" };

Say we want to filter out those that starts with the letter "t":

var result = strings.Where(s => s.StartsWith("t"));

This is the most common approach; set it up using a lambda expression. But there are alternatives:

Func<string,bool> func = delegate(string s) { return s.StartsWith("t");};
result = strings.Where(func);

This is essentially the same thing: first we create a delegate of the type Func<string, bool> (that means that it takes a string as input parameter, and returns a bool). Then we pass that delegate as parameter to the Where method. This is what the compiler did for us behind the scenes in the first sample (strings.Where(s => s.StartsWith("t"));).

One third option is to simply pass a delegate to a non-anonymous method:

private bool StringsStartingWithT(string s)
{
    return s.StartsWith("t");
}

// somewhere else in the code:
result = strings.Where(StringsStartingWithT);

So, in the case that we are looking at here, the lambda expression is a rather compact way of defining a delegate, typically referring an anonymous method.

And if you had the energy read all the way here, well, thanks for your time :)

So, to start off with the scary definition - a lambda is another way of defining an anonymous method. There has (since C# 2.0 I believe) been a way to construct anonymous methods - however that syntax was very... inconvinient.

So what is an anonymous method? It is a way of defining a method inline, with no name - hence being anonymous. This is useful if you have a method that takes a delegate, as you can pass this lambda expression / anonymous method as a parameter, given that the types match up. Take IEnumerable.Select as an example, it is defined as follows:

IEnumerable<TResult> Select<TSource, TResult>(this IEnumerable<TSource> source, Func<TSource, TResult> selector);

If you were to use this method normally on say a List and select each element twice (that is concatenated to itself):

string MyConcat(string str){
    return str + str;
}

...

void myMethod(){
    IEnumerable<string> result = someIEnumerable.Select(MyConcat);
}

This is a very inconvinient way of doing this, especially if you wish to perform many of these operations - also typically these kinds of methods you only use once. The definition you showed (parameters => expression) is very consise and hits it spot on. The interesting thing about lambda is that you do not need to express the type of the parameters - as long as they can be infered from the expression. Ie. in Select's case - we know the first parameter must be of type TSource - because the definition of the method states so. Further more - if we call the method just as foo.Select(...) then the return value of the expression will define TResult.

An interesting thing as well is that for one-statement lambda's the return keyword is not needed - the lambda will return whatever that one expression evaluates to. However if you use a block (wrapped in '{' and '}') then you must include the return keyword like usual.

If one wishes to, it is still 100% legal to define the types of the parameters. With this new knowledge, let's try and rewrite the previous example:

void myMethod(){
    IEnumerable<string> result = someIEnumerable.Select(s => s + s);
}

Or, with explicit parameters stated

void myMethod(){
    IEnumerable<string> result = someIEnumerable.Select((string s) => s + s);
}

Another interesting feature of lambda's in C# is their use to construct expression trees. That is probably not "beginner" material though - but in short an expression tree contains all the meta data about a lambda, rather than executable code.

Well, you can see a lambda as a quick way to write a method that you only want to use once. For instance, the following method

private int sum5(int n)
{
    return n + 5;
}

is equivalent to the lambda: (n) => n + 5 . Except that you can call the method anywhere in your class, and the lambda lives only in the scope it is declared (You can also store lambdas in Action and Func objects)

Other thing that lambdas can do for you is capturing scope, building a closure. For example, if you have something like this:

...methodbody
int acc = 5;
Func<int> addAcc = (n) => n + acc;

What you have there is a function that accepts an argument as before, but the amount added is taken from the value of the variable. The lambda can live even after the scope in which acc was defined is finished.

You can build very neat things with lambdas, but you have to be careful, because sometimes you lose readability with tricks like this.

As others have said, a lambda expression is a notation for a function. It binds the free variables in the right-hand-side of the expression to the parameters on the left.

a => a + 1

creates a function that binds the free variable a in the expression (a + 1) to the first parameter of a function and returns that function.

One case where Lambdas are extremely useful is when you use them to work with list structures. The System.Linq.Enumerable class provides a lot of useful functions that allow you to work with Lambda expressions and objects implementing IEnumerable. For example Enumerable.Where can be used to filter a list:

List<string> fruits = new List<string> { 
        "apple", "passionfruit", "banana", "mango", 
        "orange", "blueberry", "grape", "strawberry" };

IEnumerable<string> shortFruits = fruits.Where(fruit => fruit.Length < 6);

foreach (string fruit in shortFruits) {
    Console.WriteLine(fruit);
}

The output will be "apple, mango, grape".

Try to understand what's going on here: the expression fruit => fruit.Length < 6 creates a function which return true if the parameter's Length property is less than 6.

Enumerable.Where loops over the List and creates a new List which contains only those elements for which the supplied function returns true. This saves you to write code that iterates over the List, checks a predicate for each element and does something.

One good simple explanation aimed at developers who are firmiliar with coding but not with lambdas is this simple video on TekPub

TekPub - Concepts: #2 Lambdas

You obviously have lots of feedback here, but this is another good source and a simple explanation.

I know this is kinda old but i came here trying to make sense of all this lambda stuff. By the time i finished pouring over all the answers and comments, i had a better understnading of lambda and thought i should just add this simple answer(from a learner's perspective to learners):

Dont confuse a => a + 1 as meaning add 1 to a and return the result to a. (this is most likely a source of confusion for beginners. Instead see it like this: a is the input parameter into a function(unnamed function) and a + 1 is the statement(s) in the function(unnamed function constructed 'on the fly').

Hope this helps :)

Lambda calculus is common in many programming languages. They're also called anonymous functions in some languages. Though different languages have different syntax for lambda, the principle is the same, and their various parts are usually identical.

Perhaps the most famous one is Javascript's anonymous functions.

lol = function() {laugh()}
# is equivalent to
function lol() {laugh()}

What's the difference? Well, sometimes you don't want to go through the trouble of creating a function just to pass it somewhere once and then never again.

window.onload = function() {laugh()}
# is way easier than
function lol() {laugh()}
window.onload = lol

You can see the wikipedia article for indept information or you can skip directly to Lambda in programming in the same article.

This is just the notation of C# to write down a function value. It doesn't require giving the function a name, hence this value is sometimes called an anonymous function. Other languages have other notations, but they always contain a parameter list and a body.

The original notation invented by Alonzo Church for his Lambda calculus in the 1930ies used the greek character lambda in the expression λx.t to represent a function, hence the name.

My tip for understanding the basics of lambdas is two fold.

Firstly I recommend learning about functional programming. Haskell is a good language to start off with in that respect. The book I am using, and getting a lot out of, is Programming in Haskell by Graham Hutton. This gives a good grounding in Haskell and includes explanations of lambdas.

From there I think you should view Erik Meijer's lectures on Functional Programming as they give a great intro to functional programming as well, also using Haskell, and crossing over into C#.

Once you've taken in all that you should be well on the way to understanding lambdas.

CodeProject had a nice introductory article lately: C# Delegates, Anonymous Methods, and Lambda Expressions – O My!