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:
The world after Roslyn
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.
“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.
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.