Microsoft Previews Compiler-as-a-Service Software

angry tapir writes "Microsoft will release a Community Technology Preview of a new type of compiler its researchers have been building — code-named Project Roslyn — a company executive announced Thursday. Roslyn is a compiler for C# and Visual Basic with a set of APIs that developers can use to fine-tune their code. It resembles a model developed by the Mono Project, in which the information the compiler generates about a program can be reused as a library."

Comments

Re:Threat to Computing

[aztracker1]

I don't think you even really read the summary... it essentially comes down to offering more compile abilities into an application. This can work for extensible plugins, and scripting. It is not the compiler offered via a SaaS (Software as a Service) model.

Re:After your personal info...

[pyrbrand]

No, you're not getting it right, this is a service as in a process always running on your computer, not as in a cloud based compiler. The point is your program can dynamically call the compiler with additional source code to be compiled so your program can modify itself even though it's in a relatively static language like C#.

Re:So, why not use Mono?

[ByOhTek]

You "new" it was better? I believe the word you are looking for is "knew".

Also, Mono is an implementation/compiler for .NET, not a replacement. So, if mono is better than (Visual Studios, and the MS .NET run time, I'm guessing you are referring to?) Then I'm guessing you don't want to kill .NET because that would also kill Mono, which is .NET.

To emphasize this point, I compile programs on both Mono and Visual Studios 2010/MS Runtime. I then run programs compiled on either system to run on the other.

Both are AMAZING pieces of work.

Re:Threat to Computing

[maxwell demon]

You're assuming that two different compilers would output identical binary images, but why would they?

No, I'm not. I only assumed that two correctly working compilers would output functionally equivalent code (what I tacitly did assume was that the source-provided compiler doesn't invoke undefined behaviour, though). Note that I did not propose to compare the output of the two different compilers, but to compare the output of the one source provided compiler compiled with two different binary-provided compilers.

So say you have the source of gcc, and binary versions of Microsoft C and Borland C.

Step 1: You compile the gcc source code with Microsoft C (let's call the resulting binary vgcc).
Step 2: You compile the gcc source code with vgcc (let's call the resulting binaty gvgcc).
Step 3: You compile the gcc source code with Borland C (resulting in bgcc).
Step 4: You compile the gcc source code with bgcc (resulting in gbgcc).
Step 5: You compare gvgcc with gbgcc.

If both Microsoft C and Borland C correctly translate the gcc source code (and the gcc source code contains no undefined behaviour), then vgcc and bgcc, while not the same, have equivalent behaviour. Especially they both translate the gcc source code into the same executable. In other words, gvgcc and gbgcc must be binary identical.