Expression Trees + DLR Trees - why the duplication?

Mar 27, 2009 at 12:59 AM
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)?
Coordinator
Mar 27, 2009 at 1:04 AM

:-) 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

From: esforbes [mailto:notifications@codeplex.com]
Sent: Thursday, March 26, 2009 5:00 PM
To: Bill Chiles
Subject: Expression Trees + DLR Trees - why the duplication? [dlr:51467]

From: esforbes

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)?

Read the full discussion online.

To add a post to this discussion, reply to this email (dlr@discussions.codeplex.com)

To start a new discussion for this project, email dlr@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com

Mar 27, 2009 at 1:11 AM
Oooh - hehe, okay that makes sense, especially considering all the talk I've been hearing about expression trees being augmented in .NET 4. I guess that 'augmenting' in this case meant replacing them with DLR trees. =)

That's very good news - but what ramifications will this have on existing LINQ providers, since the expression trees they consume are getting augmented in ways the original designers probably didn't anticipate?
Coordinator
Mar 27, 2009 at 1:16 AM

First, we’re backward compatible.  Second, neither C# nor VB extended their LINQ support or lambda expressions to use any of the new ET stuff, so no LINQ provider will ever see anything they haven’t seen before in CLR 4.0.

bill

From: esforbes [mailto:notifications@codeplex.com]
Sent: Thursday, March 26, 2009 5:11 PM
To: Bill Chiles
Subject: Re: Expression Trees + DLR Trees - why the duplication? [dlr:51467]

From: esforbes

Oooh - hehe, okay that makes sense, especially considering all the talk I've been hearing about expression trees being augmented in .NET 4. I guess that 'augmenting' in this case meant replacing them with DLR trees. =)

That's very good news - but what ramifications will this have on existing LINQ providers, since the expression trees they consume are getting augmented in ways the original designers probably didn't anticipate?

Read the full discussion online.

To add a post to this discussion, reply to this email (dlr@discussions.codeplex.com)

To start a new discussion for this project, email dlr@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com

Mar 27, 2009 at 7:20 AM
What if someone constructs an expression tree using these more advanced nodes, and tries to send it to a LINQ provider?
Coordinator
Mar 27, 2009 at 3:30 PM

Yes, if you manually do that, the provider will choke :-).  Our design goal was to introduce things so that if current binaries were coded defensively, then we should always fall into their ‘else’ or ‘default’ clause for unexpected node or property settings.  We made sure that any existing nodes have no new semantics based on property values or new properties we added that current binaries would not have known to detect and change their behavior.

Cheers,

Bill

From: esforbes [mailto:notifications@codeplex.com]
Sent: Thursday, March 26, 2009 11:21 PM
To: Bill Chiles
Subject: Re: Expression Trees + DLR Trees - why the duplication? [dlr:51467]

From: esforbes

What if someone constructs an expression tree using these more advanced nodes, and tries to send it to a LINQ provider?

Read the full discussion online.

To add a post to this discussion, reply to this email (dlr@discussions.codeplex.com)

To start a new discussion for this project, email dlr@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com

Mar 27, 2009 at 6:10 PM
Ahh, I understand - excellent. =) I'm very much looking forward to this in .NET 4. =) Thanks for the information!
Coordinator
Mar 27, 2009 at 6:31 PM

Cool!  It might be worth adding that even today you can create a subtype of Expression, ball it up into a tree, and hand that to a provider who won’t know what to do with it.  That’s why they should have good defense ‘else’ and ‘default’ branches for failing gracefully already :-).

Cheers,

Bill

From: esforbes [mailto:notifications@codeplex.com]
Sent: Friday, March 27, 2009 10:11 AM
To: Bill Chiles
Subject: Re: Expression Trees + DLR Trees - why the duplication? [dlr:51467]

From: esforbes

Ahh, I understand - excellent. =) I'm very much looking forward to this in .NET 4. =) Thanks for the information!

Read the full discussion online.

To add a post to this discussion, reply to this email (dlr@discussions.codeplex.com)

To start a new discussion for this project, email dlr@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com

Mar 27, 2009 at 6:36 PM
Sage advice - I'll keep it in mind. =)

Hm - this suggests that LINQ providers in the future might be written to be capable of taking advantage of the new Expressions... Of course then LINQ will stop acting like LINQ and start acting more like...

..

Oh man, you guys are good...