Rosyln vs DLR vs Linq Expressions

Question

With regard to DSL creation and/or Metaprogramming, Do you guys have concise guidance when to use what method (Compiler as a Service, DLR, or Linq Expressions)? 

I am trying to get a feel for the demarcation lines between these technologies.

Thanks

Answer 1

I suspect a good answer would follow a long discussion of scenarios, needs, etc., but I'll take a very high-level stab, at least to try to distinguish these technologies.

The DLR uses (LINQ) Expression Trees (for those unfamiliar, see the documentation page on dlr.codeplex.com for the full spec on Expression Trees v2).  The DLR also has one vetted hosting/scripting model (full spec same site).  My current thinking is that the Roslyn Scripting APIs will be a minimal subset of the DLR Scripting Hosting APIs to support code execution so that .NET applications can use C# and VB as "scripting" languages for the apps.  I hope to post a sample using the Roslyn Scripting APIs and other Roslyn APIs to support the DLR Scripting Hosting API model so that if you wanted a .NET application that could be scripted by IronPython, C#, VB, or any DLR language, then you could take the sample to do that.  Of course, by the time we're done, the Roslyn Scripting APIs could take on any form and even perhaps solve some problems or scenarios that the DLR Scripting Hosting APIs do not since the latter did not support all important scenarios (for example, host controls on stack depth or APIs that script code could access).

Expression Trees v2 are a semantic model with some shapes resembling syntax.  They do support some control flow, assignment statements, recursion, etc.  However, they do not model many things that C# and VB can do, for example, type definitions.  The Roslyn APIs will have full fidelity with C# and VB for syntax, semantic binding, code emission, etc.

While the DLR and ETs v2 may lend themselves to some metaprogramming, their real focus was supporting dynamic languages on .NET and enabling applications to host those languages for application scripting purposes.

The Roslyn APIs will be much better suited and probably your only consideration if your goals is embedded DSLs.  The Roslyn APIs will certainly be less limiting since they will support everything languages like C# and VB can express.

Cheers,

Bill

Answer 2

Awesome, follow-up. Thanks!

When you do release the samples, what should I be monitoring (blog, forums, ...)?

Thanks,

Dave

Answer 3

It will be a while before we have this sample.  I'd like to get some more traction on the scripting api's sooner rather than later, but I'm really not sure when we can pull that sample together.  First, we need to work on the Roslyn Scripting APIs more, and when they feel like they are on a good trajectory, then look to supporting the DLR Scripting Hosting APIs on top of Roslyn.  I do not mean to say that what you see now in the Roslyn Scripting API doc is far off the final mark, I just don't know where the design will go once we really dig into it.  What's in this CTP is mostly Tomas's and my initial thinking with a bit of team review.

Cheers,

Bill

 

Answer 4

Oops, sorry, forgot your where to monitor question.  Feel free to poke me if you get curious, but otherwise, when that sample is available, we'll list it in a future release, or I'll post on this forum, etc.  If you're on the DLR mailing list, I'll likely post a message there.

Bill