Roslyn (.NET Compiler Platform) should be a Black Box

Compilers should be a black box.

We all know this.

We’re just in the moment of giddiness where we must consciously remember gravity and the physical laws of software.

So let’s get real.

Roslyn is an enormous step forward. I’ll say again that I believe the Roslyn release will go down as one of the pivotal moments in the history of computing.

But it still should be a Black Box.

“Can’t it be my favorite color?”

OK, if you don’t like the idea of a black box, make it gold, rainbow or your favorite color. As long as it is opaque.

From a Computer Science perspective it needs to be a black box with results oriented facades.

The world before Roslyn:

RoslynPre

The world after Roslyn

RoslynWithTrees

Why on earth would you care that there are trees in the box? I can talk a lot about syntactic and semantic trees. Some of us should talk a lot about them. Very few of us.

Most of us should interact with the Roslyn information through a series of interfaces, just like any other Computer Science Black Box.

RoslynWithManyInterfaces

“Isn’t that the Roslyn API?”

No. The Roslyn API represents the actual structures. Those structures have a primary purpose of supporting very fast compilation. They have a secondary purpose of supporting UI features. Support for external things is not a primary purpose, not should it be. Roslyn is a compiler released as a service. Roslyn is a compiler.

The interfaces we want are purpose specific. I drew several of them in the schematic. Clearly one is for the UI – probably another layer with the current editor services.

One is for collecting the meaning of your code. This is important for metaprogramming. I tend to get a bit stuck on that, but exactly the same interfaces can be useful to report and understand your system, and to carry forward some of it into another iteration of your application.

Either that interface, or another, will allow better reasoning about unit tests – including statistics on how your testing boundary conditions. And I expect to be amazed at the other purposes the Roslyn API will allow.

“What then?”

With such interfaces available, anyone, anywhere can write code to move from the Roslyn API into the interface. It is clear defined OSS work and can be done once, or a very small number of times. Anyone, anywhere can build on these interfaces to stretch the limits of what we can accomplish. To figuratively, reach for the stars.

We will go further faster working together with this pattern: find the purpose, gather the parties and establish interfaces – purposeful APIs. Look at mechanisms to vary and extend. Then let people go crazy creating the best implementation.

I want to be part of that conversation for metaprogramming.

I hope there’s a parallel conversation for at least one of the UI spaces – refactoring, IntelliSense, formatting, or something.

And I want the .NET Foundation to support those efforts to establish the path for community defined interface/purposeful APIs. It’s not going to be a trivial task to establish initial interface/purposeful APIs, mechanisms for extension and an ecosystem that may not fit well into other OSS process patterns.

One thought on “Roslyn (.NET Compiler Platform) should be a Black Box”

  1. You still need to pass something across an interface — tree-like things are what we need when dealing with ASTs, semantics, etc.
    Exposing data as a first-class object again is why functional programming is becoming so popular and why when writing programs like compilers that deal with systems of symbols is still most clearly done in a lispy language or something like Haskell or F# with DU’s and pattern-matching. I think exposing trees is the best thing one can do here — the alternative is to try and guess every operation some developer may want to do on a tree and provide it in an interface, then provide some kind of INav/DOM interface over the trees, which becomes hugely inefficient and inconvenient to deal with compared to rule-based rewriting of exposed trees.
    Surely Roslyn could be better structured for legions of random developers, but MS understandably didn’t make this a primary concern, and something shouldn’t be so “well formed” that it looses the intrinsic shape that is its primary purpose.

Leave a Reply

Your email address will not be published. Required fields are marked *


*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>