Professional IronPython

Understanding the Extensions to LINQ Expression Tree
 
❘
 
299
The problem with compiling everything to MSIL is that MSIL doesn’t necessarily perform tasks 
quickly or easily when working with dynamic languages such as IronPython. It would be far easier 
if there were a mechanism for translating the code directly into something that C# or Visual Basic 
.NET could use. That’s where the LINQ Expression Tree (ET) comes into play. A LINQ ET can rep-
resent IronPython or other code (such as JavaScript) in a tree form that DLR can then translate into 
something that C# or Visual Basic.NET can understand. The result is a DLR tree that presents the 
code in an easily analyzable and mutable form. The example at 
http://blogs.msdn.com/hugunin/
archive/2007/05/15/dlr-trees-part-1.aspx
explains how DRL trees work graphically. In this 
case, the author explains how a DLR tree can represent a JavaScript application — the same tech-
nique also applies to IronPython.
The LINQ ET originally appeared in the .NET Framework 3.5. In its original form, Microsoft 
used the LINQ ET to model LINQ expressions written in C# and Visual Basic.NET. In the .NET 
Framework 4.0, Microsoft added extensions for a number of reasons. For the purposes of this book, 
the most important reason to extend LINQ ETs is to accommodate the DLR semantics used to 
translate IronPython code into something that C# and Visual Basic.NET can understand.
A single section of a book can’t provide everything needed to use the DLR 
Trees. In fact, the authors of the Expression Trees specification required 173 
pages just to document the specification. You can find the specification in the 
Expr-Tree-Spec.DOC
 file found in the 
\Codeplex-DLR-0.92\Docs
 folder of 
your DLR installation. Of course, you may find that some of the information 
in this file is outdated, so be sure to check on 
http://dlr.codeplex.com/
wikipage?title=Docs%20and%20specs
 for the latest documentation.
DLR trees work in the background. It’s helpful to know they exist, but you generally won’t worry 
about them when working with IronPython so this section is short. However, let’s say you want to 
create a scripting language for your application that isn’t as complex as IronPython. Perhaps you 
want to implement an editor and everything that goes with it in your application. In this case, you 
may very well want to work with DLR trees. The examples found at 
http://weblogs.asp.net/
podwysocki/archive/2008/02/08/adventures-in-compilers-building-on-the-dlr.aspx
show what you need to do to create your own language compiler. Once you have a compiler like this 
built, you could execute the code using a technique similar to the one shown in Listing 14-2.
It’s important to consider one word of warning, however, when working with the current version of 
DLR trees. As you scan through the specification, you’ll find that the authors have left behind copious 
notes about issues that aren’t resolved now or features that were left out of the current implementa-
tion due to a lack of time. The result is conversations such as the one at 
http://stackoverflow.com/
questions/250377/are-linq-expression-trees-turing-complete
. If you look at section 2.4.1 
of the specification, you find that a higher-level looping mechanism was indeed cut, but Microsoft is 
aware of the problem and plans to implement the feature in the future. In short, DLR trees have limits 
that you need to consider before implementing them in your application.
548592c14.indd 299
2/24/10 12:49:08 PM
www.finebook.ir

---