Why Microsoft should introduce compiler extensibility

At PDC08 I attended a presentation about “Contracts” (and Pex). “Contracts” is the result of the Spec# work. It is an attempt to enable Design by Contract (DbC) in .Net. Design by Contract is a concept popularized by Bertrand Meyer, and it is fully implemented and integrated in the language Eiffel.

Microsoft decided that DbC should not be a part of the languages themselves, but rather it should be offered as a standard library. I think this is unfortunate. If it had been a part of the language, the syntax could have been more declarative, and it probably would have given DbC more power.

The problem with having DbC as just another library is that you do not get any keywords, it is not allowed to be as declarative as it could have been, and the syntax gets unnecessary verbose. And besides, if it is just another library then this is really old news. There are several DbC libraries available on the .Net platform already.

But Contracts is actually a bit more than just another library. I believe the Contracts-team, not being allowed (I suspect) to make it a part of the languages, really wanted the power anyway. And so they got creative, and did a couple of interesting things.

First, they made tools as a plug-in to Visual Studio, and these tools are there to support the library. Second they actually added post compilation. In Contracts, you define all the Contracts-library code in the beginning of the method for readability (making it more declarative). But for this to execute correctly some of the code (the ensure-part), has to be at the end of the method. What Contracts’ tools do is actually move that part of the code to the end of the method, after the code is compiled.

This is very, very interesting, and it raises the question: What is a library/framework? Normally it is just some code you can execute following the normal constraints of a language. What the Contracts-team has done is to extend the concept of what a library/framework is. They implicitly say a library/framework is both code and tools, meaning the tools can actually do some tweaking with the code after it has been written. In this case it is done for the sake of being declarative.

This means that when you create a library you get the power to add declarativeness to it, beyond the language. Now that is a very compelling concept! There are of course a couple of problems here. Creating these kinds of tools for your library is not a trivial task! Microsoft can do this because a) they’ve got the resources and b) because if all else fails, they can add support directly in the compiler, which they have already done on several occasions.

The pain here is of course, that Microsoft can do it, but you really can’t. It’s too much work, and you can forget about accessing the compiler. We as developers are not enabled to have this power.

I’ve been playing around with Boo for some time now, and I love the way Boo allows me to add keywords and to change things during compilation. My point is that Boo actually enables you to make frameworks that also incorporates tools the way the Contracts library does, and in addition it actually allows you to create keywords! And the best thing about it is that this is doable for all. It’s not very complicated. It really empowers us as developers to redefine the concept of frameworks.

If a framework can be functionality, tools and keywords then we enable us to write powerful, declarative, and less verbose code. Boo enables us. C#, sadly do not.

The very, very sad thing here is that during another session at PDC08, Anders Hejlsberg “hinted strongly” that such compiler extensibility will never, ever be available in C#.

To demonstrate “Contracts”, this is how DbC is implemented:

1
2
3
4
5

string GetDescription(int x) {
 Contract.Requires( 0<x);
 Contract.Ensures(Contract.Result<string>() != null);
 // Method body ...
}

You add a set of Requires and Ensures at the top of your method. The Requires-statements must be true at the beginning of the method, and the Ensures statements must be true at the end of the method. This means that the Ensures statements must be executed last. This is where Microsoft uses the post compilation to move that part of the code after compilation.

I have actually already made a little library for DbC in Boo, it’s very easy to do (probably only took me an hour or so to implement). This is how you say the same thing with my little library:

1
2
3
4
5

[Require(i<x)]
[Ensure(result!=null)]
def GetDescription(x as int) as String: 
	result as string
	// Method body ...

It’s got all the functionality of Contracts, it’s just as declarative (or probably even more), and in my own opinion it’s less verbose. And do not forget that it took me about an hour to implement the whole library! This is enabling developers to be more productive!

Why Microsoft does not want to enable us with this is beyond me. But regardless of Microsoft, there is nothing stopping you from using Boo!

-Tore Vestues