What are the benefits of Compiler as a Service

Question

In Anders Hejlsberg's .NET 4.0 presentation he discussed in NET 5.0 ("or some future release") they are working on a "Compiler as a Service" model.

Anders Hejlsberg's states: [source][1] "We want to open up our compiler so it becomes an API you can call to compile a piece of code and get back expression trees and/or IL. This enables a whole host of scenarios, such as application programmability, an interactive prompt, user-written refactorings, and domain specific languages that have little islands of C# imbedded in them."

I'm struggling to find a real world example where this could actually be useful. Am I missing the major concept here? or is this really going to benefit the language?

[1]: http://www.simple-talk.com/opinion/geek-of-the-week/anders-hejlsberg-geek-of-the-week/ Compiler as a Service

Answer 1

A real world example of how this could be useful is for user-extensibility for games. Most modern games allow some type of user-extensibility through scripting languages, which can be relatively slow, or through compiled DLLs which require a development platform (and the knowledge to use it). This would allow users to write extensions to the game using C#, which will be compiled by the game at runtime, without requiring the user to compile it themselves. It would also allow for testing of new ideas by entering, for instance, C# code in an in-game console window without having to restart the game for each little change. Currently this type of thing is only really possible with embedded interpreted scripting languages.

Answer 2

I think one more example is copy protection. You could have a unique piece of code on your machine, generated on installation to tie a program to a CPU ID.

Let's say that I use your serial number as a parameter in tax calculation. A copy of the program is easy to do and totally useless.

Answer 3

For some problems, it is easier to write a program that can generate a program that will solve the actual problem. One area where this is particular useful is for building parsers for compilers.

In other cases, you can generate code on the fly which can be tailored to provide optimum performance when working with a particular data type, about whose properties you just learned at runtime by reflecting over its metadata. One example I can give you for that is my Modelshredder project. What it basically does is taking all the fields and properties of an object and packs their value into an object array.

My first approach to that problem was hand coded MSIL injection using Reflection.Emit. The second approach was a little more dynamic and relied on Expression Trees, which can effectively be constructed and compiled at runtime to provide the same functionality as my hand coded MSIL injection. You can see that realised in the MoreLinq trunk (just have a look at the Modelshredder site, there's a link for that). Having Compiler as a Service would actually allow me to raise abstraction level and emit C# code which will then get compiled to MSIL.

The case for Domain Specific Languages has already been made, also I think that an imperative language like C# is not well-suited for the "command line" scenario but rather than for bigger scripts. There's a neat make system based on an F# DSL called FAKE, which borrows a lot of concepts of Compiler as a Service. Similar concepts are employed by the F# Interactive Window (is it called that way?) inside VisualStudio.