locked
Expression Trees? RRS feed

  • Question

  •  

    Hi!

    I am trying to get my mind around Expression Trees and how to use them to solve business problems. Could someone explain the architectural purpose in a real-world scenario? Do I want to consider using them for building say a dynamic “rules engine?” I think this interesting, but why do I want to do this?

    Expression<Func<int, int>> exprInc;

                    ConstantExpression constant = Expression.Constant(1, typeof(int));

                    ParameterExpression parameter = Expression.Parameter(typeof(int), "n");

                    BinaryExpression add = Expression.Add(parameter, constant);

                    exprInc = Expression.Lambda<Func<int, int>>(add, new ParameterExpression[] { parameter });

                    ret = exprInc.Compile()(6);

                    Console.WriteLine(String.Format(exprInc.ToString() + "={0}", ret));

    Thanks!

    Friday, July 11, 2008 5:56 PM

Answers

  • Probably not.  Expression trees are useful in cases where you might want to accept a code declaration, like a Linq query expression or a lambda function, but are not sure that you'll actually need to execute the code.  That's important in the C# 3.0 language, the fact that the user wrote code to declare a Linq expression doesn't actually mean it would be necessary to run the expression.  The use of the expression is disjoint from the location where it is declared.  In normal every-day user code, you write code that only gets executed when it gets called, you don't pay for code that was written but doesn't get called.

    If you are implementing some kind of scripting language for your app, expression trees might be useful.  Lamda functions have general goodness, but the expression trees that make them work are already provided in the box.  I'm guessing it got a good bit of press time because the C# team is pretty proud of their accomplishment.  Deservedly, seeing generic types used that way by the masters is an awesome sight.  But it is just plumbing.  If you think "expression tree might be useful here", think lambda first.

    Having said all this, I bet there's somebody that has a killer application for it.  I'd be interested.

    Hans Passant.
    • Marked as answer by Zhi-Xin Ye Thursday, July 17, 2008 7:36 AM
    Saturday, July 12, 2008 12:43 AM
  • As far as I know the LINQ team needs expression trees for two reasons:

    1. Translate identical query code into several different execution formats, depending on the target of the query, i.e. either SQL or C# operating on different collection types.

    2. Optimize query code because a certain part might be redundant (I believe that's what Hans hinted at).

    So expression trees are useful if you need an intermediate format for scripting that your program will convert into various flavors of optimized executable code.  You'd have a parser that converts scripts into expression trees, and then you'd have a translator and optimizer to generate executable code from those expression trees.

    Expression trees are not useful if you don't require such an intermediate format.  That's the case for most scripting systems -- you just write a C# method that does exactly what you want, and directly change that method when necessary.  Expression trees are no use in such cases.
    • Edited by Christoph Nahr Saturday, July 12, 2008 6:52 AM blah
    • Marked as answer by Zhi-Xin Ye Thursday, July 17, 2008 7:36 AM
    Saturday, July 12, 2008 6:51 AM

All replies

  • Probably not.  Expression trees are useful in cases where you might want to accept a code declaration, like a Linq query expression or a lambda function, but are not sure that you'll actually need to execute the code.  That's important in the C# 3.0 language, the fact that the user wrote code to declare a Linq expression doesn't actually mean it would be necessary to run the expression.  The use of the expression is disjoint from the location where it is declared.  In normal every-day user code, you write code that only gets executed when it gets called, you don't pay for code that was written but doesn't get called.

    If you are implementing some kind of scripting language for your app, expression trees might be useful.  Lamda functions have general goodness, but the expression trees that make them work are already provided in the box.  I'm guessing it got a good bit of press time because the C# team is pretty proud of their accomplishment.  Deservedly, seeing generic types used that way by the masters is an awesome sight.  But it is just plumbing.  If you think "expression tree might be useful here", think lambda first.

    Having said all this, I bet there's somebody that has a killer application for it.  I'd be interested.

    Hans Passant.
    • Marked as answer by Zhi-Xin Ye Thursday, July 17, 2008 7:36 AM
    Saturday, July 12, 2008 12:43 AM
  • As far as I know the LINQ team needs expression trees for two reasons:

    1. Translate identical query code into several different execution formats, depending on the target of the query, i.e. either SQL or C# operating on different collection types.

    2. Optimize query code because a certain part might be redundant (I believe that's what Hans hinted at).

    So expression trees are useful if you need an intermediate format for scripting that your program will convert into various flavors of optimized executable code.  You'd have a parser that converts scripts into expression trees, and then you'd have a translator and optimizer to generate executable code from those expression trees.

    Expression trees are not useful if you don't require such an intermediate format.  That's the case for most scripting systems -- you just write a C# method that does exactly what you want, and directly change that method when necessary.  Expression trees are no use in such cases.
    • Edited by Christoph Nahr Saturday, July 12, 2008 6:52 AM blah
    • Marked as answer by Zhi-Xin Ye Thursday, July 17, 2008 7:36 AM
    Saturday, July 12, 2008 6:51 AM