I need to get more productive. University is enormous fun, but a lot of my free time seems to come in bite-size chunks which aren't useful for getting things done it. I either need to increase my productivity or scale back my commitments - prolly my open source ones :(

More object-model thoughts

I wish I had time to work on this stuff, but I don't. As a compromise I might as well write up my thoughts. Maybe somebody else will see them and act on them, or at least get interested as a result.

Recently I have started to fancy the D language. It's cute. More importantly, it's not cute in a theoretical abstract way, it's cute because it is an extremely practical language. Physically it resembles Java or C#, however it has lots of features and more importantly fits into the traditional workflow - there is a compiler which outputs native .o binaries given input text files. Those binaries have no external dependencies (assuming you statically link the fledgling standard library). There are no VMs.

Unfortunately, D currently has a few problems which make it unsuitable for use in the free software community. The first is the lack of a free-speech compiler. The second is the lack of a working GObject bridge, which means that despite excellent C compatability, it does not have access to any Linux APIs.

As I pondered this problem, an idea occurred to me - what if instead of a random home-grown ABI for D on Linux, an experimental compiler was written that output GObject C. The resultant C could be compiled using gcc (one of the main blocking issues for a GNU D compiler is the complexity of writing gcc frontends).

Why would this be interesting? Basically, because it means that you could write a class in D (think similar to C++ but cleaned up), compile it, then use it from C with no intermediate stage. An extra step or two could make it automatically bound into Python, perhaps with the bindings embedded in the same shared library that the original code is in.

Ahhh... we would be one step closer to a unified object model on Linux. So what are the difficulties with this approach?

The most obvious one is that D has many constructs that cannot be supported natively in C, like exceptions. Exception handling in C *is* possible, it's done on Windows (google for "win32 seh"), but we currently have no standard for it on Linux as far as I'm aware. Other constructs that might cause problems would be visibility modifiers on methods, and method overloading. Ideally there'd be an obvious mapping from symbols in D to symbols in C (which would be their native "mangling"), however making method overloading reliable would make this a lot harder.

Nonetheless, the possibilities are interesting. There's no real need to create a home-grown ABI for D on Linux, rather, we can reuse what already exists. Another alternative would be to write a D compiler for .NET, however D can be at times quite low level, for instance, it's possible to have direct mappings onto C structs and export D functions with C linkage (indeed, this is one of its assets), so I'm not sure the .NET CTS would be a good match here.

Unfortunately I don't have time to work on this project.