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 ;).