The idea is that we’re doing some interesting things at work and some of those things are not related to the IP or profitability of our company so we’re trying to contribute to open source. We’re doing the best we can and trying to put as much as we can responsibly put in there in order to contribute to the community.

We realize that it’s not terribly useful for other people if it’s a hodge-podge and they can’t discover what’s in it or how to use it. At this point, we have a list of things to do on ShadeTree to make it more friendly for use by people other than us.

My hope with this blog post series was to try to make some of the gems that are in ShadeTree a little more widely known so you can at least grab some nuggets until we can polish it up a little.

If you or anyone else is willing to help put some docs together, I’d be willing to spend some time on the phone/skype getting you started and walking through the important things. Sometimes, just having the bootstrapping for documentation (i.e. the outline, layout, styles, etc) helps encourage more people to write more.

Would you (or anyone else here) be willing to get a documentation shell project going in ShadeTree (an empty HTML project with CSS layout and maybe just some basic ‘getting started’ docs? Maybe a wiki instead?)?

No worries at all! I really digging the new C# features and am doing my best to understand all the in’s and outs. I really like how the expression trees are helping to bridge some of the “metaprogramming gap” that exists at the moment. The NHibernate mapping stuff that you and Jeremy have been doing is a good example I think. Really looking forward to seeing what else you guys come up with!

Thanks again for the catch! Sorry I was being so dense. I updated the post accordingly. Let me know if works for you.

Yeah, I think I’m mistaken with the CS0201 thing you pointed out. I forgot that the compiler automatically adds the “return” keyword deep under the hood to lambdas like that.

I’ll correct that later tonight (gotta run right now, unfortunately).

Both you and Jimmy pointed out my mistake with trying to pass the block as type Expression – yep, I was totally wrong with that one.

However, I’m still not satisfied :)

— chad wrote
If you later try to execute/invoke that expression, THEN you’ll get an error similar to the CS0201 above. But for right now, the compiler lets it pass, and will generate the IL to pass your method or property a type of Expression<>.
—

I can’t figure out how to write an expression that is fine at compile time, but will result in a CS0201 style error when you try to run it. I would really really love an example of this.

Thanks for being patient with me.

I think I’m starting to understand what you’re pointing at here.

Like I said above in my reply to Rob, yes, c=>c.LastName will work as a Func parameter because the compiler will translate c.LastName as a “return c.LastName” statement, which is, of course valid. So there’s some compiler trickery happening there so MAKE an otherwise invalid statement, valid.

One note, you’re using blocks {} around your lambda. That won’t work with the Expression stuff like what I’m talking about (for static reflection purposes). And the static reflection stuff doesn’t work with Action, it must be Func.

Sorry for being such a persistent bugger about this, but I still can’t seem to replicate the magic you are describing. Would you mind pasting an example of a lambda expression body that doesn’t compile unless you make it a parameter to a method that takes an Expression?

This fails to compile for me:

[Test]
public void Test()
{
Magic(s => { s.Length; });
}

private void Magic(Expression> action) { }

The Expression Tree magic only appears to happen when the Expression is a parameter to a method. I don’t think it works as a standard assignment or even a Property setter assignment.

If you wish to build up expression trees manually, you can use things like:

Expression.Lambda()
Expression.MakeMemberAccess()
Expression.Equal()
Expression.AndAlso()
etc,etc,etc

Sorry, I probably wasn’t clear enough. I understand the difference, and why you need to use Expression instead of a plain Func in your example. You can interrogate the expression tree if its an expression, you can’t if its a plain old func. What I don’t understand is this:

— chad wrote:
You might, rightly, expect to get this compile error:

error CS0201: Only assignment, call, increment, decrement,
and new object expressions can be used as a statement

So why don’t you? Well, the trick is that your method or property must take a parameter of type Expression>.
—

Unless I’m mistaken, the answer to “why don’t you?” is that the compiler allows us to elide the return, braces and semicolon. src=>src.Name is perfectly valid, because its equivalent to src => { return src.Name; }. You get this behavior regardless of whether you are using an expression or just a normal func.

And If this statement was true:

— chad wrote:
This causes the C# compiler to behave strangely — namely it does not treat the code inside the expression as executable code, but as a parsed language element for LATER evaluation.
—

Then this line would compile:
Expression> exp = s => { s.Length; };