I've decided to laying the foundation for creating bindings of the GNOME software stack for Scheme48, specifically: create bindings for GLib/GObject.
At the core of GNOME, there is the GLib Object System (GObject), on top of which GTK+ and the rest of the developer platform are built. Thanks to the header scanning tool h2def.py, which creates a S-Expression representation of the API, you are able to create bindings for any GObject-based library, once you got the core bindings right.
I have a rough plan how to do this; basically I plan to fork guile-gnome and reuse the existing infrastructure (e.g. .defs processing). The Guile-GNOME fork will drive a G-Wrap that's capable of emitting code for the upcoming Scheme48 FFI. Work on G-Wrap/Scheme48 has already progressed to a degree where it's possible to turn to the GObject bindings and fill out the holes as needed in the process.
The plan is also to make the resulting bindings "mostly compatible", so that programs written for Guile-GNOME will also work with Scheme48-GNOME and vice versa. Since Scheme48 has no built-in object system, and the object system would have to be compatible with GOOPS (Guile's object system) anyway to achieve source-compatibility between the bindings, I started working on a GOOPS-compatible version of TinyCLOS.
I'm curious as to why a Scheme48 binding is helpful or desirable to you. Specifically, why Scheme48 above its alternatives, and likewise, why GNOME above its alternatives?
As I'm not only interested in just using the language implementation, but also on the internals, both because having insight into them can teach you a lot of things and because of nececessity: sometimes you have to be quite familiar with the implementation internals to make certain applications or (esp. extensions). As chalst already explained, Scheme48 is a very "hackable" implementation and has several features that make it technically interesting. Besides the VLISP project, there is also Kali Scheme built upon it, a distributed extension of Scheme48 that makes distribution transparent to a degree rather unimaginable in "mainstream" languages. As for choosing Scheme over alternatives: IMO, the Lisp family, with its powerful syntactic macro systems, and Scheme in particuliar (hygienic macros, continuations), are on the upper end of the spectrum of expressiveness of computer languages (at the other end would be assembly/machine code).
Now GNOME: I chose that, because it's written in C, which has the following desirable properties:
- It's rather simple, esp. when compared with it's "big (and ugly, IMO) brother" C++.
- The simplicity makes it easy (or easier, at least) to create bindings for C libraries.
Furthermore, GTK+/GNOME was written with language bindings in mind and provides an API taylored towards that. Also, I'm already involved with guile-gnome and thus have already a good bit of experience in GNOME language bindings. Last but not least, GTK+/GNOME as opposed to QT (the obvious alternative) is a real community-driven project.
All I have to say is that I'm all for it. It would also be nice to have sort of "partial" bindings like plain Gtk+. Not all desktops are running full gnome or want to install all of it.
I hope it will also make it to distributions and porters/packagers instead of being just another crufty binding hidden somewhere.