in Uncategorized

Full Expression Tree Support Coming in .NET/C# 4.0

Yesssssssss! I’ve been waiting and hoping that this was coming in 4.0 and now it’s official: Full Expression Tree Support. This seems like a HUGE step forward to me. With the advent of this feature, one can finally implement support for converting an expression written in C# to something that runs on the GPU. For example, this would enable a scenario in the future where we can actually write WPF shader code using C#/VB and they can be considered safe because a “GLINQ” interpreter could inspect the statements before it converts them to shader code directly on the fly at runtime.

I haven’t blogged in forever (something I want to get back into), but this news warranted a post immediately. Really excited, hope I can find some time to tinker with starting a expression tree based GPU library.


Ah, darn it. Looks like I read the post wrong. While full support is coming to the expression library, it looks lilke C# 4.0 will still not implement compiling of full method bodies into expression trees. Do they really think that having the ability to hand write expression trees by hand with the expression library is of any use? ‘Cause I don’t really see it happening… gotta have the language support for it to take off. : 

Guess it’ll be another four years of not being able to implement something like rich GPU support inside of .NET languages. 🙁

Leave a comment


  1. I think the full expression tree support is in there to support the Dynamic Language Runtime. But it looks like they’re planning what you want for C# 5.0. See the last part of Ander’s presentation on the Future of C#: They’re planning to introduce a feature called Compiler as a service – my guess is that that will utilise Expression Tree support.

  2. Hi folks,Sorry to hear the disappointment about expression trees only being available as a library in the .NET 4 timeframe. Samuel is right to conclude that the tree support is there to fuel the DLR, and it made sense to avoid reinventing the wheel, hence making the new node types and extension on top of the System.Linq.Expressions types introduced the previous go-round.When and if full "quotation" support will happen in future releases of the languages is still an open-ended question AFAIK, but the compiler-as-a-service plans hinted at by Anders show some of the directions the team is thinking of for the releases to follow. Having an object model to represent code will be a major advantage going forward, facilitating lots of scenarios.Hope this helps,-Bart

  • Related Content by Tag