How to make a Side-by-Side Compiler for .NET

Question

Nikhil Kothari's Script# is quite possibly one of the most amazing concepts I've seen in the JavaScript arena for quite some time. This question isn't about JavaScript, but rather about language compilation in the .NET runtime.

I've been rather interested in how, using the .NET platform, one can write a compiler for a language that already has a compiler (like C#) that will generate separate output from the original compiler while allowing the original compiler to generate output for the same source during the same build operation, all the while referencing/using the output of the other compiler as well.

I'm not entirely sure I even understand the process well enough to ask the question with the right details, but this is the way I currently see the process, as per diagrams in the Script# docs. I've thought about many things involving complex language design and compilation that may be able to take advantage of concepts like this and I'm interested in what other people think about the concepts.

--

Edit: Thanks for commenting,so far; your information is, in it's own right, very intriguing and I should like to research it more, but my question is actually about how I would be able to write my own compiler/s that can be run on the same source at the same time producing multiple different types of (potentially) interdependent output using the CLR. Script# serves as an example since it generates JavaScript and an Assembly using the same C# source, all the while making the compiled Assembly cooperate with the JavaScript. I'm curious what the various approaches and theoretical concepts are in designing something of this nature.

Answer 1

It's important to realize that all a compiler does is take a source language (C# in this case), parse it so the compiler has a representation that makes sense to it and not humans (this is the abstract syntax tree), and then does a naive code generation to the target language (msil is the target for languages that run on the .NET runtime).

Now if the script# code is turned into an assembly and interacts with other .NET code, that means this compiler must be generating msil. script# is using csc.exe for this, which is just the standard c# comiler. Now to generate the javascript, it must take either c# or msil, parse it, and generate javascript to send to the browser. The docs says it has a custom c# -> js compiler called ssc.exe.

To make things interact consistently on both the client side and the server side it has a set of reference assemblies that are written in .NET but are also compiled to javascript. This is not a compiler specific issue though, those reference assemblies are the script# runtime. The runtime is probably responsible for a lot of the script# magic you're perceiving though.