DLR Trees == LINQ Expression Trees?

Appears so - at least, once .NET 4 ships.

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:

Me:

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.

Bill

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.

Arrrgh

Slow Visual Studio builds make me a SAD PANDA.

Long silence

It's been over a month since my last post - I'm sorry about this. I have a horrible tendency to forget my blogs, as my MySpace friends can attest to. I have an excuse this time though - my workload has effectively doubled at the office, and I've had to budget my time recently.

I also spent some time down at my company's warehouse getting to know the warehouse staff and seeing the physical processes that drive the company. It was definitely an eye-opening experience - this was the first time I've ever visited a warehouse of any sort, and seeing them physically carry out the processes that I've helped to develop was gratifying in a way. It helped me to fully understand the ramifications of the decisions that I make when building the software that they'll use.

My spare time (hah!) has been spent getting the new bot up and running - so far, so good! :) I have a command-line version up and running that is fully configurable and about 70% functional - no hunting functionality is in, but harvesting works a charm. I've opened up beta applications on the Macrocrafter website, so you should hop over there if you're interested in helping me test.

The development process has been much easier this time around, I think. I wasn't very smart with the first few iterations of the harvest bot - during the alpha and beta periods I pretty much wrote EverHarvest by the seat of my pants, largely without a plan at all. The result was that after the command-line tests were complete, I had to completely rewrite the system because I had coupled it into the command-line project. This time, I'm developing the engine of the system completely separate from the UI - it's in its own separate assembly - which will make it *much* easier to move from the command-line interface to the graphical interface.

So these are the developments of late. Nothing earth-shattering, but lots of things to distract me from blogging. I'll try to keep up moving forward. =)