G-Wrap is a wrapper generator written in Scheme, currently running on Guile and easing the task of wrapping C libraries for Guile Scheme.
It's current model is mostly based on emitting C code that implements wrapper functions that Guile knows how to call, which means they take and return SCM values and are registered with the interpreter, also specifying the number of arguments they take. The code is constructed by a hierarchy of so-called code generators (or CGs for short). The code generators are functions (or rather methods, G-Wrap uses GOOPS since version 1.9) that return nested lists (trees) of strings, which constitute the C code to emit. Various code generators are invoked for various purposes, e.g. there is a global-declarations-cg that is supposed to emit the global C declarations.
One issue with G-Wrap is that the code generators are awkward to write, since they are wild mix of strings of C code and "normal" Scheme code. There has been an idea about fixing this problem: introduce a S-EXP syntax for C code. There already is something like this for Common Lisp, but I can't dig up the link right now. Anyway, there is a probably much easier and more elegant approach, as is clear after reading Foreign Interface for PLT Scheme. When the target Scheme implementation supports a Scheme-level FFI like the one detailed in this paper, G-Wrap's task becomes much easier: there is no need to construct and emit C code anymore! Furthermore, a Scheme-level FFI can probably be implemented for every Scheme implementation with a capable C interface, and there's no need to make them incompatible to the implementation for PLT Scheme. This opens the possibility for reuse of binding code across implementations, which is impossible with the current approach, since the C code embedded is highly specific to the C interface of the Scheme implementation and these differ a lot from each other.
Here are my plans on how to do this experiment with G-Wrap: