“If now, while they are one people, all speaking the same language, they have started to do this, nothing will later stop them from doing whatever they propose to do.” – Genesis XI, v.6

I was surprised by how easy it was to implement the collector. It is a very simple one (stop-the-world, two semi-spaces etc.) but nevertheless I always thought garbage collectors were somewhat magical, a bunch of elves that worked out of sight to keep your process working perfectly. This is exactly why I am writing such a system, even if it never gets free onto the world it will fulfill its purpose. Of course, if I am satisfied with the result, I will release the beast.

I have been using Scheme for almost four years now. I use it mostly for studying programming languages and programming in general, prototyping and testing new ideas, but I have also developed and sold applications written in Scheme to customers. I believe Scheme is nowadays a maximum in the design space of programming languages and is the language of choice of some of the best hackers of the world. I thus deeply wish that Scheme gets getter with each new standard revision.

I have come across one of the many design decisions a compiler writer faces. When compiling let forms, they are first translated to the closed lambda applications they are syntatic sugar for. For instance:

(let ((a "Alex")
      (e (+ (* pi 2) 1))
      (i (car (cons 1 0))))
  ((if a + -) e i))

Becomes:

((lambda (a e i) ((if a + -) e i))
 "Alex" (+ (* pi 2) 1) (car (cons 1 0)))

There is no need to emit code to create full closures when compiling closed lambda applications, because they cannot be applied multiple times. Instead, the environment is extended during compilation and the body is compiled in this new environment, but still it is considered just a piece of the enclosing body. So far so good, but what does happen during execution?

During the execution of the virtual machine, the arguments to full closures are pushed onto the stack (along with a return address, saved frame pointer and number of arguments pushed), before jumping to the closure code. Currently, when entering the body of closed lambda applications, a lightweight closure calling protocol is used: Just the frame pointer and the arguments are pushed onto the stack and are latter popped. But when accessing bindings not local to the current scope, which is very common in let forms when one access the arguments of the enclosing full closure, the compiler has to emit code for jumping through activation frames until the desired one is found, and the binding is found there. In other words, the VM instruction for accessing bindings is LOAD i j, where i is the activation frame level and j is the index of the binding inside that activation frame.

Although this works, it is not as fast as it could be. I am planning to use flat environments as described in Dybvig’s PhD thesis so all access to bindings inside closures will have constant time, not linear on the depth of the desired binding. The current compilation of closed lambda applications defeats that optimisation, although it makes bindings somewhat shallower. The alternative is to look for all the bindings introduced by closed lambda applications during compilation and always allocate space for all of them in the stack. This uses (possibly much) more memory because allocates space for bindings that may never be needed during execution, but accessing any binding is again constant time because all of them are known at compile time.

As usual, it boils down to memory versus speed. I guess I’ll leave it as is for now and worry more about speed after the compiler is able of even compiling itself.

Some may say Ruby is a bad rip-off of Lisp or Smalltalk, and I admit that. But it is nicer to ordinary people.

Now that is a demotivator. But Ruby must be evolving, and that quote may be outdated. So I have thought of a question to the Ruby-lovers, that may help me make up my mind to take the time to learn it. One of the best Scheme macros is, in my opinion, and-let*, from the SRFI-2. How would one write the following in Ruby, a procedure that I wrote a couple of nights ago?

;; Tries to get session from current request
(define (get-session request)
  (and-let* ((cookies (request-cookies request))
             (p (assoc "session_id" cookies))
             (sid-str (cdr p))
             (sid (string->number sid-str))
             ((integer? sid))
             ((exact? sid))
             (sp (assq sid *sessions*)))
    (cdr sp)))

In the and-let* macro, the clauses are evaluated and the variables are bound sequentially, creating new scopes for the next expressions. If any of the forms evaluates to #f (false in Scheme), the computation is aborted, no other expressions are evaluated, and the whole form evaluates to #f. How would I write this in concise Ruby?

I am not a heavy user of object orientation, but I can certainly see its value where it is worth. In the LiSP book, for instance, a beautiful interpreter and a compiler are written in OO-style, in chapter 3 and 10, respectively. Another example is writing a scene graph for a Computer Graphics application, it almost begs to be written object-oriented.

Bradley himself replies, in which he explains that his code is roughly half as fast as it would have been if coded in C, but the memory bandwidth is the culprit and it does not matter anyway. An interesting part of the email is this:

I didn’t mind rewriting the level-1 BLAS code in Scheme, however, as it didn’t seem worth the trouble to get a small speedup in the entire system just to use a dot-product or saxpy written in C and called from an FFI. I have enough difficulty in getting students to admit to themselves that, yes, this system is fast (just about as fast as any expert could have written it, and probably much faster than your average graduate student could have written it) and it’s flexible (it’s only at the end of the course that some students reluctantly admit that they could not have finished their semester project in their favorite language, whether C or C++), and that the speed doesn’t arise from level-1 BLAS written in C (because they’re written in Scheme). One point that most students seem to take away from the class is that multigrid is one hell of a lot faster than conjugate gradient, and many of them have been using conjugate gradient in their own projects simply because it’s too hard to program multigrid in C or C++ (at least the first time you try it). So one gets a lot of speedup simply by being able to program more sophisticated algorithms.

There is also a toy ray-tracer written in Gambit-C, Schemeray, which was further optimised by Marc Feeley, and even more by (again) Bradley Lucier. The times are impressive, thanks to all the clever compiler tricks Gambit-C uses when generating C code, like inlining, partial code evaluation and generating one C function per Scheme module (avoiding expensive inter-module C calls).

The code generated by Gambit-C is fast enough for 99.99% of the applications out there. And this is using a strong, dynamically-typed language, with first-class closures and continuations, arbitrary-precision numbers, and the powerful macros of the Lisp family of languages. There is hardly need to use C or C++ even in the most demanding applications. The same cannot be said of Perl, Python or Ruby, whose applications usually run much slower than one created with Gambit-C. And, if the need really arises, interfacing Gambit-C with C code is extremely easy.

I have departed from the traditional approach of implementing a Scheme interpreter in Scheme itself because I wanted to avoid possible confusions between the defined language and the defining language. This has made a lot of the concepts clearer. The evaluator is written in continuation-passing style, which is easily done in Lua because the latter has tail-call optimisations. This way it is easier to reify continuations to first-class values.

I have also added a few primitives to allow me to run some examples, as the factorial and fibonacci functions. More primitives can be easily added if desired.

Ok, I know the World is already sick of Schemes, it only takes a look at this list to know why. But I still think I have to do it, if only for my personal learning. There is no need to bore the World to death with another half-done Scheme. Sometimes I think about features that could make my Scheme useful, though. They are probably never going to be implemented, but here they are:

Full R5RS compliance

The R5RS is a piece of art (R6RS, on the other hand, is a stain, a mess). Of course it does not describe a terribly useful system, but it beautifully describes the core of one. Everything else can then come from there. For more compliance with other systems, the SRFIs can be used as the basis for a standard library.

Bytecode virtual machine

Although Scheme is a dynamic language, there is a lot that can be known about the program before executing it. Lexical variables, never assigned variables, closure and continuation creation etc. This can be processed at compile time, allowing for a simple and fast virtual machine. Interpreting the source code directly is easier but very inefficient for any serious system.

Incremental garbage collection

Stop-and-go garbage collectors are easier to implement, but in some applications the pause is inacceptable. For applications like interactive games, the smooth user experience only can be achieved by an incremental garbage collector. It would be nice if it was a moving collector too, to avoid too much fragmentation of the heap (some naive C programmers think the use of malloc and free can beat a garbage collector in any circustances, until they are hit in the face by heap fragmentation. There is a reason the Apache web server uses memory pools). If I remember correctly the CLR garbage collector is very good and compacts the memory without the use of from- and to-spaces, which is cool, because uses less heap memory. Hmm, while I am dreaming about my ideal garbage collector, make it concurrent too (see below).

Concurrency

These days the hot topic is concurrency. New personal computers with two and four cores sell more and more every day. The programming languages/environments that makes easy for the programmer to use these new cores are going to be big. Erlang is the hottest thing right now in this regard, although Haskell is a strong candidate too. In the mainstream Java has a concurrent VM, but Java uses the old lock/unlock paradigm of other mainstream languages, Clojure is the new language on top of the JVM that leverage that power for the programmer. But although this is all so hot, the only thing that seems to be happening to Scheme is Termite, which as far as I know can only use green threads. My hypotetical Scheme would have a concurrent VM, some Scheme compilation techniques already give a start in that direction. There would be maybe a spawn-continuation form that would take a continuation captured with call/cc and resume it in parallel with the current one, in a M:N model (M continuations spread on N OS threads).

Just-in-time compilation

Well, once dreaming, why not go all the way? One of the nice things about Scheme is the bottom-up, incremental development. Developing at the REPL gives instant feedback and ease debugging. What if it could give the speed of compiled-to-CPU languages as well? Another advantage is hot-swapping code in a running application. This can’t be done with Chicken or Gambit, which are fast, but Scheme-to-C compilers. Larceny, Chez and Ikarus can do this. By using a bytecode VM, the system is portable to wherever there is a C compiler, and by adding JIT support for some architectures it can be made fast too.

Escape continuations

Full, first-class continuations with indefinite extent are a powerful and mind-bending feature, but unfortunately, are usually hard to implement and causes pauses when invoked. Besides them, my hypotetical Scheme would have escape continuations. Instead of completely overwriting the execution stack, they simply unwind it until some recorded point, which can be made very fast. Exceptions would them be implemented as escape continuations rather than full ones.

Easy FFI

I am a long-time Lua user, and it is amazing how they could get the C API so good. Not only it is very easy to add new C/C++ libraries to Lua, it is trivial to embed the Lua interpreter itself in a legacy application, or an application that needs to be mostly in C/C++, such as games. As Scheme, unfortunately, is not one of the World’s favorite languages, the capacity to talk to the outside World is fundamental. And by being embeddable (which is the goal of Guile, but it sucks for Windows), it would be easier to take Scheme to another domains where it is not so popular today.

Well, I guess this is it. Thinking about it, there seems to be no Scheme system today with all these features. Will I have the skills to write something like this after LiSP? I doubt it, only the garbage collector would take me ages. But it would be nice if such thing existed…

Although the focus of Dybvig’s thesis is not on concurrency, I cannot help but think that his compiler could work very well for this too with just minor modifications. If variables (local or free) are never assigned, they could be replaced by their values and several different threads with different execution stacks could run in parallel. If a variable is assigned, the access to its indirection box could be protected by a mutex or similar synchronisation primitive. Of course this would make access to assigned variables even slower, because even variables ever used by only one single thread would need mutex lock/unlock operations. On the other hand, isn’t assignment discouraged in Scheme? The overall execution time would compensate for this, if the rest of the program was parallelised.

But surely I am missing something, because no one ever seems to think Scheme can be a contender in the massive-parallelised future. What bugs me is that I don’t know what it is that I am not taking in consideration.