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.