Cristian Vlasceanu is working on porting the D compiler to the .NET platform.
For our readers who haven’t heard of D, how would you describe it?
D is a multi-paradigm language: it has object orientation support, it allows functional and template meta programming and even includes untamed features such as a goto keyword and inline assembly.
I heard Walter Bright (the father of D) describing it as a language invented by a compiler implementer (not a language designer). That may be true, and indeed some of the most successful software projects came out of their authors' need to scratch an itch. However, Walter' s description may undersell D, because he definitely designed it with users in mind and not just with what syntax would make parsing easier to implement.
In many ways D encourages the "right" behavior. For example, in C and C++, if you write "int i;" the variable is uninitialized. To do the "right thing", the programmer needs to type extra keystrokes as in "int i = 0;" but D works the other way around: "int i;" safely sets the variable to a default value (that in this case is zero). To make it uninitialized you have to spend extra effort and type "int i = void;" expressing that the uninitialized variable is intentional and not due to laziness.
Why did you originally decide to start writing a D compiler?
This project is only about writing the back-end part of the compiler. The front-end is based on Walter' s compiler, which he made available as open source. I am trying not to change the front-end if I can help it.
I had the opportunity to work with interpreter front-ends in my career, but had limited experience with code generators. And because I do most of my work in C++, I did not get much exposure to .NET (and C#) until recently. A .NET code generator project is an excellent learning opportunity in both directions. That's one reason.
Another reason is that a compiler implementation for .NET (even if only a prototype) brings a great and mature computing framework to the D community; it opens the road for painless inter-operation with other languages supported on .NET.
I have some (anecdotal) evidence that part of the D community swears by native code as far as performance is concerned; without a compiler implementation the alleged advantages of native code cannot be proved nor disproved.
Would you consider this to be a research project or are you aiming for production use?
It is a research project. I do not know what kind of reception to expect from the D community (I plan to release the code within a few weeks and find out). I also do not know how much time I will be able to devote to this after-hours project. I hope the project will grow over time to the point of being of production-use quality. But for now it is in the trail blazing phase.
On your blog, Programming and Debugging (in my Underhøøsen), you talk about a lot of the compatibility issues you’ve had building the compiler. Which compatibility issue do you see as being the most interesting or difficult?
By far, array slices are a proverbial pain the proverbial you-know-what. D has this feature where if you have an array of (say) integers "x", and you write "int[] y = x[2..5];" it means that "y" is a "view" into "x", starting with element at index two and ending at (but not including) the fifth element. So "y" is a sort of a light-weight object, rather than a copy of a range of elements. In .NET there is a similar concept called an ArraySegment. An ArraySegment (which is a value type) is a very distinct type from an array.
D does not really make distinction between arrays and slices. If you have a function signature such as "foo(int [])" it will happily accept arrays and slices as its input. I find it confusing for the programmer and very difficult to get right inside the compiler' s code generator. My current solution is inefficient because it involves a lot of hidden conversions from arrays to ArraySegments and vice versa. I hope to convince Walter to change D 2.0 so that array slices get their own distinct type. An array and a view into that array are distinct concepts and should be modeled as such.
But other than that, things are going smoothly because of the many similarities that I find between D and .NET (and C#).
What features of D do you like to see implemented by the CLR and/or C#?
D has a feature called "class invariants": you can write a method with the reserved name "invariant". The compiler generates the code to call this method after construction, before and after public methods, and before destruction. The body of the method is typically made of a bunch of assert statements, but you can put whatever sanity-checking code in there. It is very, very useful for debugging. I would not mind seeing something similar in C#. But then again, I am mostly a C++ guy.
That sounds a lot like the Object Invariants feature of Code Contracts.
Yes, it is the same principle, but with a few differences (if I read the documentation right). D does not require reflection nor external tools (such as the ccrewrite utility), contract programming is a "first citizen" language paradigm. Maybe I am not fully appreciating the versatilty of the contracts library, but it looks intimidatingly complex. I find D's way leaner and easier to understand.
Now that you've had a chance to work on this for a while, do you still like the CLR as a platform for compiler development?
The more I learn about it, the more I get to appreciate the CLR. I find it convenient to focus on language features rather than on the gruesome details of vtable layout, or stack unwinding (for example).
Do you have any interest in the Dynamic Language Runtime, either in general or for D?
Good question. Unlike Python and Ruby, D is statically typed. My first instinct is that I do not need the DLR for this particular project. But I may take a look at it though, I wonder if it could help me solve the array slice conundrum that I mentioned earlier.