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

So let's say you want to compile C# into Javascript. You are asking whether you can take advantage of the existing C# compilers, so instead of compiling C# into Javascript directly you actually convert the MSIL generated by the C# compiler into Javascript?

Sure, you can do that. Once you have the MSIL binary you can do whatever you want to it.

Answer 2

Microsoft has a research project called Volta which, amongst other things, compiles msil to JavaScript.

a developer toolset for building multi-tier web applications using existing and familiar tools, techniques and patterns. Volta’s declarative tier-splitting enables developers to postpone architectural decisions about distribution until the last possible responsible moment. Also, thanks to a shared programming model across multiple-tiers, Volta enables new end-to-end profiling and testing for higher levels of application performance, robustness, and reliability. Using the declarative tier-splitting, developers can refine architectural decisions based on this profiling data. This saves time and costs associated with manual refactoring. In effect, Volta extends the .NET platform to further enable the development of software+services applications, using existing and familiar tools and techniques.

You architect and build your application as a .NET client application, assigning the portions of the application that run on the server tier and client tier late in the development process. You can target either web browsers or the CLR as clients and Volta handles the complexities of tier-splitting. The compiler creates cross-browser JavaScript for the client tier, web services for the server tier, and all communication, serialization, synchronization, security, and other boilerplate code to tie the tiers together. In effect, Volta offers a best-effort experience in multiple environments without requiring tailoring of the application.

Answer 3

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.