My blog is now wordpress-powered, please adjust URL.
I began to program in Scheme using the Guile interpreter. While I knew that its not blazingly fast, its the official GNU extension language, and as feeling quite close to the goals of the GNU project and the FSF, I felt confident it was the right choice, also considering the supreme quality of other GNU software, such as the GNU toolchain (GCC, binutils, gas) and the Gimp, to name just a few.
So, feeling confident with my choice, I started to crank out code and eventually even took over maintainership over a Guile application, namely G-Wrap, after giving it a complete brush-up code-wise. When Tom Lord, of GNU Arch fame (and coincidently a former Guile maintainer), announced the Pika project (a from-scratch Scheme implementation, with ambitous goals), I decided to get on the mailing list and lurk, and later got opportunities to contribute a bit. Unfortunatly that project stalled due to time constraints on Tom's side. Anyway it was a very valuable experience, as it opened my eyes to other Scheme implementations, foremost Scheme 48. Looking at its code base was a real eye-opener: as opposed to Guile, it was, except for a tiny amount of glue code, written in Scheme; its virtual machine is written in a subset of Scheme called Pre-Scheme that can be compiled to efficient C code, so you get most of the benefits of Scheme and the speed of C.
Around the same time I discovered Scheme 48, I got involved in conjure, a make replacement being written in portable Scheme. I split off the library code from it to form a separate project, spells. As spells is basically a layer above the individual Scheme implementations which hides away their differences and presents their features (foremost the module system, but also hash tables, file system access, ...) in a portable way, I gained some experience regarding the different module systems and how they compare, and I honstly must say that Guile's is basically unusable with macros. Here's why:
A decent module system allows for macro code to refer to bindings in the module they are defined in, without requiring these bindings to be also exported; imagine a macro that expands to a call to some helper procedure that should itself should not be visible from outside the module. A real-life example are the reference implementations of SRFI-34 and SRFI-35, which define the helper procedures guard-aux and type-field-alist->condition, respectively. This deficiency (which is not present in Scheme 48, PLT Scheme, Gauche and probably most other Schemes) is really unfortunate, as it makes modules, when used with macros, a lot less usable. This, besides the total orientation toward interpretation and the codebase that is mostly in C are reasons why I'd recommend Scheme newbies also looking at other options before settling on Guile because it's the "official GNU extension language", as I did ;).
I'm going to get paid for open source developement! Wooha! More specifically, the company I work for since 2 months is going to switch away from CVS as SCM tool.
We had a look several SCM systems, among them Subversion, GNU Arch and several commercial offerings, including BitKeeper :-0. The final contestants were GNU Arch and AccuRev. Subversion fell flat for its missing features (mediocre merging support, no distribution), and BitKeeper was not considered seriously because they don't even list prices at their site (which indicates a fairly high price tag, normally ;) and due to opposition from myself (for the obvious political reasons).
Well, finally the case was made for GNU Arch, and since it lacks a decent GUI (currently the GUIish guys here use WinCVS), it was decided to develop the GUI in-house, and as an open source project!. It will probably be developed using Python and GTK+, so it will run also on Windows (which is a requirement). Expect more news, including project announcement soonish.
Mike Sperber finally reviewed my patches; they unfortunatly were not deemed appropriate for the Scheme48 distribution, see this thread. Hopefully these issues can be sorted out in the not-to-far future. If you also need the one or other features from my hacks so far, and are adventurous, you can conact me on #scheme on freenode for help with getting and building my fork.
Writing portable Scheme programs with scmxlate and spells
For the conjure project, we are using scmxlate to make it portable across multiple Schemes. For that purpose, I slightly extended scmxlate and built a kind of meta-module system on top of it. Here is how that looks like:
You write a description of the modules your application or library is made of; this is done in a sightly extended subset of the Scheme48 configuration language. For example (from this page, see there for more details):
(define-structure conjure.foo.bar (export qux baz ((froboz fribnitz) :syntax)) (open scheme srfi-1 srfi-13 conjure.util.files) (dialect (guile (open ice-9.syncase)) (scheme48 (open extended-ports))) (files (foo basic-bar) (foo bar)))
This defines the module conjure.foo.bar, which exports the identifiers qux and baz, as well as the macros froboz and fribnitz. The open clause means: this module is written in R5RS Scheme (scheme), plus additionally using srfi-1, srfi-13 and the conjure.util.files module. The dialect clause can be used for specifiying additional modules needed for the dialect-specific code for the module. Finally, the files clause tells us that this module consists of the files foo/basic-bar.scm and foo/bar.scm.
This file then gets processed by scmxlate, generating a file with the right module definitions for the selected target dialect, e.g.:
(define-module (conjure foo bar) #:use-module (srfi srfi-1) #:use-module (srfi srfi-13) #:use-module (conjure util files) #:use-module (ice-9 syncase)
#:export (qux baz) #:export-syntax (froboz fribnitz))
;; code for foo/basic-bar.scm and foo/bar.scm follows
will be generated for Guile.
We recently split scmxlate and the meta-module systeem out of conjure, see the scmxlate category in the conjure archive, so it is available for other projects. Now the split-out of the general purpose modules into a separate project -- SPELLS, (S)pell's a (P)ortability (E)nvironment (L)ibrary for (L)ots of (S)chemes -- is in preparation. This library will further aid writing portable code, by providing a consistent interface to functionality that has different APIs in different Schemes. These modules are already there:
All of those are implemented for all of mzscheme, Guile, Scheme48 and Gauche, using native functionality where available. Other modules will surely follow, a project has been requested at Gna! to facilitate contribution. The spells library will also be used by my upcoming port of G-Wrap to Scheme48.
Over the last months, I've started several hacks on Scheme48. My interest in Scheme48 was initially sparked by Jivera, who started to bring a Pika-style C API to Scheme48.
The features/projects I've been working on:
scheme48 -cl packages.scm -o mystructure
which is equivalent to typing:
,config ,load packages.scm ,open mystructure
at the Scheme48 prompt.
Most of the above is still not polished and not ready for release or even sending patches upstream. I have, however, submitted some very simple patches to the Scheme48 mailing list, and got no response from the maintainers. Should working with them not work out, I might have to create my own fork of Scheme48. In fact I have forked already, but if I can't get (parts) of my stuff into mainline Scheme48, I might start to actively push my fork as "extended Scheme48" or with a new name.
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.
New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.
Keep up with the latest Advogato features by reading the Advogato status blog.
If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!