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.4.8 Extending the Compiler

At this point we take a detour from the impersonal tone of the rest of the manual. Admit it: if you’ve read this far into the compiler internals manual, you are a junkie. Perhaps a course at your university left you unsated, or perhaps you’ve always harbored a desire to hack the holy of computer science holies: a compiler. Well you’re in good company, and in a good position. Guile’s compiler needs your help.

There are many possible avenues for improving Guile’s compiler. Probably the most important improvement, speed-wise, will be some form of native compilation, both just-in-time and ahead-of-time. This could be done in many ways. Probably the easiest strategy would be to extend the compiled procedure structure to include a pointer to a native code vector, and compile from bytecode to native code at run-time after a procedure is called a certain number of times.

The name of the game is a profiling-based harvest of the low-hanging fruit, running programs of interest under a system-level profiler and determining which improvements would give the most bang for the buck. It’s really getting to the point though that native compilation is the next step.

The compiler also needs help at the top end, enhancing the Scheme that it knows to also understand R6RS, and adding new high-level compilers. We have JavaScript and Emacs Lisp mostly complete, but they could use some love; Lua would be nice as well, but whatever language it is that strikes your fancy would be welcome too.

Compilers are for hacking, not for admiring or for complaining about. Get to it!