I've been doing some research on the DLR lately, for no other reason than sheer boredom - and came away fascinated. The DLR (Dynamic Language Runtime) is .NET's answer to dynamic languages running in the .NET environment. It's still in beta at this time (DLR is version .9 as of this writing), but already many languages have been implemented on it - the most famous of which are the Iron languages - IronPython and IronRuby.
The way it works (and I'm simplifying things here) is thus: you provide the translation from source code to DLR trees, and the DLR provides IL generation, fast execution, a proven garbage collector, and the entire .NET Framework. Sounds like a bargain to me. DLR trees are syntax trees that tell the DLR how to generate code - you have things like AssignmentExpression, StatementExpression, LambdaExpression, etc.
A lot of this sounds very similar to what you get right now with LINQ Expression trees. In fact, there was an announcement a short time ago which stated that LINQ Expression trees were going to be getting an upgrade. Currently (.NET 3.5) LINQ Expression trees can only represent simple logic - property lookups, method invocations, things like that. You currently cannot express an IF statement, for example, inside a LINQ Expression tree. With .NET 4.0, that's going to be changing - LINQ Expression trees will be augmented with the functionality it's currently missing.
This is great news for LINQ implementors, to be sure - but seems to me to be a bit redundant. LINQ expression trees and DLR trees are starting to sound a lot alike - so I popped on over to the DLR's home on CodePlex and asked about it:
Not sure if this is the right place to ask this, but here goes:
Why is there so much duplication between these two incredibly similar tasks? Why couldn't Expression Trees have been implemented as DLR Trees (or vice versa)?
Them (specifically, Bill Chiles):
:-) You’re like the audience plant to ask just the right questions :-).
They are the same. LINQ Expr Trees v1 evolved into Expr Trees v2 which are exactly the DLR tress. All the sources you see in our codeplex project are the sources we’re shipping in CLR 4.0 for all of the Expr Trees code. What might be confusing is that until we RTM CLR 4.0, we change the namespaces on codeplex. We need to do that so that if you have a .NET 3.5 C# app that both uses LINQ and hosts, say, IronPython, then LINQ works as well as the DLR. You just can hand those threes back and forth, which would be a very corner case scenario if one at all. When we hit RTM, the codeplex sources will will have the same namepace, but we won’t build the Microsoft.scripting.core.dll in our .sln file.
So, there you have it - DLR Trees == LINQ Expression Trees. Very cool stuff happens when you explore the possibilities here - consider a LINQ to SQL provider that might be capable of understanding your custom C# logic and translating that into the equivalent TSQL code -- or, even better -- send the DLR tree over the wire to SQL Server which can run it on a DLR implementation there!
That would be just awesome...
Here is the thread on CodePlex where I chat with Bill about the trees, in case you'd like to see the follow-ups.