
Microsoft previews Roslyn: .NET Compiler-as-a-Service infrastructure - lmkg
http://msdn.microsoft.com/en-us/roslyn
======
lmkg
So I read Eric Lippert's blog post on Roslyn[1], where he says the motivation
for the project was because other teams within Microsoft were re-implementing
parts of the C# compiler piecemeal, so it made sense to expose those parts as
an API. You know what that reminds me of? Steve Yegge's Platform rant.
Specifically, the part where Bezos made Amazon convert all of their existing
development infrastructure into services, that other units can make use of.
That's what Roslyn is, on a much smaller scale: refactoring an application
(the compiler) to be services-oriented platform.

[http://blogs.msdn.com/b/ericlippert/archive/2011/10/19/the-r...](http://blogs.msdn.com/b/ericlippert/archive/2011/10/19/the-
roslyn-preview-is-now-available.aspx)

~~~
mullr
Not really, no. It's more like a compiler as a library with a nice API.

~~~
barrkel
Libraries can be platforms too.

Platforms are a mode of operating when providing, on an ongoing basis,
something that third parties use. There are several "promises" around
platforms: a promise not to break compatibility, a promise not to coopt client
software features, and - oddly enough - a promise to be incomplete, so that
third parties have opportunities to build.

------
Jupe
I think this is quite interesting. The ability to treat code as data is an
incredibly powerful concept. I don't know exactly what Roslyn does, but I see
a lot of potential:

1\. Measuring code complexity. I've often felt that code complexity can be
gauged several ways, and one is the number of "if" statements (or
select..case). Being able to query the code base of an extremely large
solution is a big step in that direction.

2\. Being able to "query" the call stack - how do I get from this line to the
base constructor of my "user" object. Rather than stepping through the
debugger, it could be a query of the code base to find the path from here to
there.

3\. Detecting bit-rot. Finding any method class that's simply never used could
be another "query" of the code base. Yes, proper test-coverage would help
detect this, but not every production system has unit tests.

4\. I've worked on projects in the past where we really wanted to add guid
tracing to the preamble of each function to dynamically trace the code at run
time. If Roslyn supports "update" queries of the code, it might be easy to add
such a feature across the whole code base (or perhaps only classes that
inherit from some known base class).

Managing a code base like this (rather than grepping/searching) is a powerful
concept. Perhaps we could see a LINQ for source code some day?

~~~
SeveredCross
I agree with all of your points, though the only one I can address is the LINQ
for source code quip and amend it somewhat to an already possible "LINQ for
codebases." It should, in theory, be just a few weekends worth of work to use
Mono.Cecil (<https://github.com/jbevain/cecil>) to provide a nice queryable
API to inspect an (already compiled) codebase. I'm sure some nice static
evaluation tools could be written based on this that nobody's thought of yet.

That said, being able to inspect the source-code pre-compilation is a whole
other level above and beyond—as a fan of the compile-time safety that
statically-typed languages provide, any opportunity to eliminate bugs and
complexity before the code makes it to a customer is a welcome one, and if
Roslyn is good, it could be huge.

~~~
solutionyogi
Roslyn will be good. It has to be because from what I understand, the MS team
themselves will use Roslyn in Visual Studio and other products. Roslyn isn't
just a public API for others to analyze code. It will be the foundation on
which .NET framework languages will depend upon.

See Eric Lippert (Member of the Roslyn team, C# Principal) notes here:

[http://blogs.msdn.com/b/ericlippert/archive/2011/10/19/the-r...](http://blogs.msdn.com/b/ericlippert/archive/2011/10/19/the-
roslyn-preview-is-now-available.aspx)

~~~
SeveredCross
Well…I think Roslyn will be good, but I think it's reaching to say it must be
because the MS team themselves will use it.

After all, these are the same people who invented (and used!) MFC, long known
as the Microsoft _Frustration_ Classes.

~~~
xpaulbettsx
1992 called and wants its Microsoft stereotype back.

~~~
SeveredCross
It was a joke, lighten up. For what it's worth, I'm a .NET developer and think
it's awesome.

------
duncan_bayne
Interesting. Some years ago my business partner and I wrote a server in Ruby
on Rails that used Mono to compile customised .NET assemblies on the fly.
Worked very nicely for our problem domain but was ultimately scuppered by CAS
workarounds.

------
equark
If Rosyln is written in C# does this mean Roslyn can run on Mono?

------
chrisbennet
I image keeping my development tool in Redmond ensure I keep paying fees but
what does this do for developers?

~~~
bjg
As mentioned in the link, there are two presentations you can view.

Interesting demo during BUILD:
<http://channel9.msdn.com/Events/BUILD/BUILD2011/TOOL-816T>

You can skip to 35:40ish

Cool presentation from MSR:
<http://research.microsoft.com/apps/video/?id=152281>

You can skip to around 5:00

~~~
mullr
The build video is somewhat amusing to me. The crowd was WAY into the REPL
demo, wherein they showed things that any dynamic language has been doing for
decades, all the while trumpeting the "power of static typing". There IS power
in static typing, but by the time you're in the REPL you don't need much of
it.

~~~
jules
Intellisense in a REPL based on static type information is novel, as far as I
know. Some dynamic languages do this based on dynamic type information, but
that is limited to expressions whose value is known. For example you have a
variable A in scope at the REPL, and it has a method A.foo(), then you'll get
completion on .foo. But you'll not get completion on A.foo().bar(), because
the value of A.foo() is not known at the time of typing that expression.

