A couple of months ago I was tasked (at my day job) with making a legacy piece of C++ business logic inter-operate with another team's C# code. It was a small, one week project, but it forced me to pick up some .NET stuff along the way. Long story short, I was so intrigued with the maturity and elegance of the technology that I decided to push the exploration further, on my own time.
A friend and colleague of mine expressed interest in the past in writing a compiler back-end for the D language, that would generate .NET assemblies. So we met and re-discussed the project and decided to give it a go. The D language features map onto .NET quite well: there's no multiple inheritance of implementation, but one class can implement any number of interfaces; structs are value types, the D language is garbage-collected with provisions for explicit destructors (just implement IDisposable), and there are static constructors (.cctors in .NET).
D has static destructors also, which I found really easy to implement by generating code that registers a ProcessExit handler, like this:
// register static dtor as ProcessExit event handler
call class [mscorlib]System.AppDomain [mscorlib]System.AppDomain::get_CurrentDomain()
ldnull
ldftn void dtor.Base::'_staticDtor1'(object, class [mscorlib]System.EventArgs)
newobj instance void [mscorlib]System.EventHandler::.ctor(object, native int)
callvirt instance void [mscorlib]System.AppDomain::add_ProcessExit(class [mscorlib]System.EventHandler)
ret
Our approach so far is to generate IL assembly code, and then invoke ILASM. This way we are portable (the code so far works on Windows as well as with Novell's mono) and easy to debug.
We got some basic flow control working, and exception handling and assertions are also supported. But there's a long way to a fully-working compiler.
We intend to make the project open source (as soon as we decide upon the license -- I kind of hate the GPL for being anti-business and anti-profit, but the jury is still out on this one).
I think this is not just a great opportunity to bring the D language to the .NET family's table, but also give D programmers access to the wealth of libraries and utilities written for .NET to date.
4 comments:
LGLP would be a great choice then (gtk+, glib, gstreamer are under it & more).
LGPL would be a very poor choice. It is as toxic as the GPL in the sense that it forces derivative works to be released as open-source. The fact that the freetards that wrote gtk+ etc, chose to use it is not a compelling reason to put my own intellectual property in the slimy hands of Richard Stallman.
Why a compiler would need BSD? I don't know about any business modifying, say, C# compiler and shipping with their own project.
I imagine that once the project is released people may want to fix bugs or make enhancements (for example, we currently generate IL textual code, it is very likely someone may want to try and use System.Reflection.Emit instead). So the license should allow users apply their changes freely.
Post a Comment