Linq Expressions – From and to delegates


I’m getting quite a few hits on my blog regarding Linq Expressions and how to convert those to and from delegates, so I figure I can just as well make a small post about it.

From Delegate to Expression;

This is not really possible, you can never cast or convert an existing delegate into an expression tree.
You can however assign lambda expressions to expression trees exactly the same way as you assign them to a delegate.

//assign a lambda expression to a delegate
Func<int> myDelegate = () => 1 + 2 + a +b;

or:

//assign a lambda expression to an expression tree
Expression<Func<int>> myExpressionTree = () => 1 + 2 + a +b;

Notice that you do exactly the same thing, except that the expression tree version wraps the delegate type inside a generic expression class.
The C# compiler will figure out what your intentions are and compile the code in completely different ways for those two cases.
This is the reason why you can not use "var" as the type for a lambda assignment, the compiler have no way to figure out if you want a delegate or an expression tree, or even what type the delegate should have.

The first case will generate an anonymous method that is assigned to the delegate var "myDelegate".
While the expression tree version will complile the expression into code that builds the expression tree and then asigns the result to the Expression var "myExpressionTree".

You can also pass lambda expressions exactly the same way;

//pass a lambda expression as a delegate

Foo( () => 1 + 2 + a +b );

....

void Foo (Func<int> myExpressionTree)
{..}

or:

//pass a lambda expression as an expression tree

Foo( () => 1 + 2 + a +b );

....

void Foo (Expression<Func<int>> myExpressionTree)
{..}

Note that the calling code looks exactly the same in both cases, it is only the definition of the methods that are called that differs.
This is also how Linq to Objects and Linq to SQL works.

The Linq to Objects provider uses delegates, while the Linq to SQL provider receives expression trees that are later converted into ad hoc SQL statements.

So in short, the compiler can compile the same expressions into two different forms, but you can not cast or convert from a delegate into an expression tree.

From Expression to Delegate;

Linq expression can not be casted or converted into delegates, they can however be "compiled" into delegates.

eg:

//create an linq expression
Expression<Func<int>> myExpressionTree = () => 1 + 2 + a +b;

//compile the expression into a delegate
Func<int> myDelegate = myExpression.Compile();

The above code is ofcourse useless, you should of course not create expressions and then immediately compile them into delegates.
That would be silly since you could assign the lambda into a delegate directly.

However, there are cases where you might want to add code in between the creation of the expression and the delegate compilation.
eg. you might want to analyze the expression and take certain actions depending on the contents of the expression tree and if some criteria is met, compile the delegate.

The most common reason why you would want to compile linq expressions into delegates is however a completely different story.
Since .NET 3.5 , there are a complete namespace of expression classes.
You can manually build expression trees using those classes and call compile on that tree in order to compile it into CIL code.
This means that you can use the Linq Expression trees as the foundation of a simple compiler.

And as of .NET 4.0, we are getting even more power for our expression trees, the entire Dynamic Language Runtime is build around the Linq Expressions.
So you can build expression trees containing if statements, for loops, variable declarations, assignments etc etc.

But more about that in another post :-)

//Roger

About these ads

An intentional extensible language?


Ever since I first saw Lisp I have had a sort of hate love for it.
The syntax is horrible to look at, but at the same time it is pure genius in the sense that you can add new language constructs since everything are functions.
I have never seen any other language that can do this.

For those of you who don’t know what I’m talking about;
Pseudo lisp:

 (foreach
      (item list
            (print item)))

"foreach" is not a keyword here, it is a function that takes a variable name as it's first argument, a list as it's 2nd argument and a list of statements as it's 3rd argument.
So even if it looks ugly as sin, _everything_ will look exactly the same, you can add a new concepts that looks as if they were part of the language due to the simplicity of the Lisp grammar.

There have also been countless of attempts to try to de-parenthesis Lisp, so that you get something that is actually readable.
But as far as I know, none of those attempts have been successful.

I always like a good challenge, so the last few days I have been sketching on a grammar that would actually allow you to extend a language and still be able to read it.

My attempt is based on what I call chain-expressions.

A chain expression consists of;
* one or more symbols
* an optional parenthesis group that contains other chain expressions
* an optional bracket group that contains other chain expressions

This allows you to write expressions like this:

//single symbol expression
break; 

//symbol + parenthesis group 
print ("hello");  

//symbol + parenthesis group + bracket group
if(foo)
{
 ...
};

That looks fairly decent, doesn't it?
But what about that semi colon at the end of the "if" block?

The semi colon represents the end of a chain of chain expressions.
My grammar allows me to link multiple chain expressions together, like this;

if(foo)
{
 print ("foo is true");
}
else if (bar)
{
 ...
}
else
{
 ...
};

What you see above is a chain of three chain expressions.
If , else if and else, and the chain is terminated with the final semi colon.

The "if" expression would be implemented as a function in my language where the function takes a boolean expression as it's first argument, and a list of statements (the bracket group) as it's 2nd argument.
and a reference to the "next" expression, that is, the "else if" expression.

If we try to express the Lisp example at the top of the post using this grammar it would look something like this:

foreach item in list
{
       print (item);
};

So it would in practise work pretty much like Lisp, where functions or code is passed around to other functions, but with a far more readable syntax, at least in my own opinion ;-)

This would allow you to create true DSL's without knowing how to write a grammar, which you have to know if you use parser frameworks like M Grammar or Gold Parser.
It would also enable you to step into the world of intentional programming using text based code instead of using a structured editor like most other intentional programming tools forces you to do.

Currently I've only got a working grammar for this, so the next step will be to create a compiler or engine so that I can run real programs in it.

//Roger

Evolutionary Compression


When I first posted the “Evolution of Mona Lisa” post, there were a few questions raised regarding how well an evolutionary approach to image compression would work out.
A few days later, some guys at the NVidia forms started to try out the concept using hardware accellerated graphics.
That attempt was fairly successful, it was better than normal JPG, but worse than JPG2000.

Now there is another attempy made by Neil Graham, you can read his article about it here: http://www.screamingduck.com/Article.php?ArticleID=46&Show=ABCE 
This attempt seems to deal much better with fine details than the CUDA version did.

I think that the final results shown in that article are awesome, although I would like to have seen some reference images using other compression algorithms with the same data size.

//Roger