Warning: This is the manual of the legacy Guile 2.0 series. You may want to read the manual of the current stable series instead.

9.1.5 Status, or: Your Help Needed

Guile has achieved much of what it set out to achieve, but there is much remaining to do.

There is still the old problem of bringing existing applications into a more Emacs-like experience. Guile has had some successes in this respect, but still most applications in the GNU system are without Guile integration.

Getting Guile to those applications takes an investment, the “hacktivation energy” needed to wire Guile into a program that only pays off once it is good enough to enable new kinds of behavior. This would be a great way for new hackers to contribute: take an application that you use and that you know well, think of something that it can’t yet do, and figure out a way to integrate Guile and implement that task in Guile.

With time, perhaps this exposure can reverse itself, whereby programs can run under Guile instead of vice versa, eventually resulting in the Emacsification of the entire GNU system. Indeed, this is the reason for the naming of the many Guile modules that live in the ice-9 namespace, a nod to the fictional substance in Kurt Vonnegut’s novel, Cat’s Cradle, capable of acting as a seed crystal to crystallize the mass of software.

Implicit to this whole discussion is the idea that dynamic languages are somehow better than languages like C. While languages like C have their place, Guile’s take on this question is that yes, Scheme is more expressive than C, and more fun to write. This realization carries an imperative with it to write as much code in Scheme as possible rather than in other languages.

These days it is possible to write extensible applications almost entirely from high-level languages, through byte-code and native compilation, speed gains in the underlying hardware, and foreign call interfaces in the high-level language. Smalltalk systems are like this, as are Common Lisp-based systems. While there already are a number of pure-Guile applications out there, users still need to drop down to C for some tasks: interfacing to system libraries that don’t have prebuilt Guile interfaces, and for some tasks requiring high performance.

The addition of the virtual machine in Guile 2.0, together with the compiler infrastructure, should go a long way to addressing the speed issues. But there is much optimization to be done. Interested contributors will find lots of delightful low-hanging fruit, from simple profile-driven optimization to hacking a just-in-time compiler from VM bytecode to native code.

Still, even with an all-Guile application, sometimes you want to provide an opportunity for users to extend your program from a language with a syntax that is closer to C, or to Python. Another interesting idea to consider is compiling e.g. Python to Guile. It’s not that far-fetched of an idea: see for example IronPython or JRuby.

And then there’s Emacs itself. Though there is a somewhat-working Emacs Lisp language frontend for Guile, it cannot yet execute all of Emacs Lisp. A serious integration of Guile with Emacs would replace the Elisp virtual machine with Guile, and provide the necessary C shims so that Guile could emulate Emacs’ C API. This would give lots of exciting things to Emacs: native threads, a real object system, more sophisticated types, cleaner syntax, and access to all of the Guile extensions.

Finally, there is another axis of crystallization, the axis between different Scheme implementations. Guile does not yet support the latest Scheme standard, R6RS, and should do so. Like all standards, R6RS is imperfect, but supporting it will allow more code to run on Guile without modification, and will allow Guile hackers to produce code compatible with other schemes. Help in this regard would be much appreciated.