The separate phases of the compilation process have their uses, too. For example, according to a blog post by Microsoft's Eric Lippert (Silverlight required), various groups have written their own C# language parsers, even within Microsoft. Maybe the Visual Studio team needed to write a syntax-coloring component, or maybe another group wanted to translate C# code into something else. In the past, each team would write its own parser, of varying quality. With Roslyn, they can simply access the compiler's own syntax parser via an API and get back a syntax tree that's exactly the same as what the compiler would use. (Roslyn even exposes a syntax-coloring API.)
The syntax and binding data exposed by the Roslyn APIs also makes code refactoring easier. It even allows developers to write their own code refactoring algorithms in addition to the ones that ship with Visual Studio.
Hejlsberg's most remarkable demo, however, showed how Roslyn's syntax tree APIs make it remarkably easy to translate source code from one CLR language to another. To illustrate, Hejlsberg copied some Visual Basic source code to the clipboard, opened a new file, and chose Paste as C#. The result was the same algorithm, only now written in C#. Translations back and forth don't yield identical code --
for loops might translate into, say,
while loops -- but in all cases the code was perfectly valid, ready to compile, execute, or refactor.
Can I have it now, please?
The catch: Hejlsberg wouldn't commit to a ship date for the Roslyn technologies or even that they'd make it into a shipping Visual Studio release. For that matter, he wouldn't comment on any future Visual Studio releases or whether there would be another version at all. Even the Roslyn CTP release is running a little late. At the Build conference running Sept. 13 to 16, Hejlsberg said it would arrive "in four weeks." It arrived yesterday -- a week late -- instead.
Don't think Roslyn is too far-fetched to happen, though. It's actually very similar to the Mono project's
Mono.CSharp library, which exposes the Mono C# compiler as a service and enables a REPL console much like the one Hejlsberg demoed at Build.
Mono.CSharp has been shipping with Mono since version 2.2.
The main drawback of Roslyn is that it's a complete retooling of the .Net compilers, rather than of the platform itself. That means it's limited to C# and Visual Basic, at least for its initial release. If developers using other .Net languages want to take advantage of Roslyn-like capabilities, those languages' compilers will need to be completely rewritten.
But maybe they should be. If Microsoft succeeds with everything it has planned, Roslyn represents not merely a new iteration of the Visual Studio toolchain but a whole new way for developers to interact with their tools. It breaks down the barriers between compiled and dynamic languages and enables powerful new interactive capabilities in the coding process itself. It truly is one of the most ambitious and exciting innovations in compiler technology in a long time.
This article, "Microsoft's Roslyn: Reinventing the compiler as we know it," originally appeared at InfoWorld.com. Read more of Neil McAllister's Fatal Exception blog and follow the latest news in programming at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.