Ever since the Scheme R⁶RS roadblock, I've been looking to branch out into other Lisps outside the Scheme ecosystem. The good news is that there's no shortage of nascent Lisps and Lisp-wannabes, with many interesting new undertakings being launched month upon month.

There's one in particular, called Clojure (pronounced closure), that was unveiled recently and effortlessly stands out from the bunch. There's much to like about Clojure, but first and foremost, it follows a principle I'm very fond of: code talks, bullshit walks.

The electoral vote regarding the ratification of the final R6RS draft closes momentarily. After spending much of the weekend giving this latest draft a fair reading (which took some work as it has ballooned to over 160 pages, contrasted with the 50 pages that sufficed to define R5RS), I’ve bit the bullet and voted against ratifying it. As all votes and their explanations will eventually (as of August 26) be a matter of public record, here is the ballot I submitted, with formatting and relevant hyperlinks added:

Deliberating on the latest R5.97RS draft I find much that is agreeable about it, and it would be tempting to vote for its ratification. Indeed if but the programming language described therein would be named anything else than Scheme, it might seem the promising start of a practical and useful modern Lisp dialect.

Yet as the R5.97RS main and library reports still read today, the resulting language is most definitely not Scheme. My primary issue with the draft is that it betrays the spirit of its very own opening paragraph: “Programming languages should be designed not by piling feature on top of feature, but by removing the weaknesses and restrictions that make additional features appear necessary.”

I should very much hope that paragraph will never be removed in future RnRS reports! Evaluating the rest of the main and library report against that principle, I think it stands out that the draft has simply suffered considerable feature creep and is vastly overspecified and overcomplex. In a word, it is too ambitious (or presumptuous, depending on your point of view).

I’m convinced the draft as it stands would derail Scheme, in the sense of putting the language on a course that it is unlikely could be easily corrected through later RnRS iterations. Thus I must at this time, with apologies to the editors, vote against ratification and hope that there will be enough dissenting voices to reopen the editorial process.

If the vote concerned only the main report in something not too far from its present form, ratification would not be an unfeasible prospect; and this despite the report having almost doubled in size. I do share others’ misgivings on issues such as requiring the full numeric tower and chaining Scheme at the hip to Unicode; still, the main report all in all appears decent, and a standardized library definition facility, even if the current proposal seems rather overcomplex, would be a most important practical benefit provided by core R6RS.

However, the proposed standard library report is simply unacceptable. Not only does it gratuitously eschew important and widely-used existing SRFIs (such as the SRFI-1 list library, and SRFI-69 hash tables) in favor of its equivalent incompatible functionality, but one must ask why features such as, say, byte vectors, enumerations and hash tables should even be included in the RnRS reports in the first place?

The desire for a standard library is widespread, both for reasons of portability and practicability, but I think it is clear that when it comes to library functionality, the SRFI process has proven itself and works better than the committee process being voted on here. Attempting to evolve a standard library through the rightly slow-moving RnRS process seems to me shortsighted and counterproductive in the long run.

Thus, I consider the standard library report largely superfluous and indeed harmful. Instead of attempting to set in stone a controversially large standard library with the RnRS process, I believe the R6RS committee should strictly confine itself to the core language only, and fully embrace the SRFI process for the standardization and dissemination of all non-essential library features.

I, Arto Bendiken, do solemnly offer these my responses to The Road to Lisp Survey:

When did you first try Lisp seriously, and which Lisp family member was it?

I read Peter Seibel’s Practical Common Lisp and Paul Graham’s On Lisp sometime in mid-2005 or thereabouts. Both proved to be useful introductions to Common Lisp and gave me an initial appreciation of the unique characteristics of Lisp-derived programming languages.

After being sufficiently enlightened by those two books, I moved onward to Scheme. This came about primarily as a result of struggling my way through the Wizard Book and watching the 6.001 video lectures, as well as perusing various online tutorials and papers. I’ve been programming in Scheme ever since, with the occasional foray into Common Lisp.

When Paul Graham’s A Plan for Spam made its dramatic entrance into the anti-spam battle four years ago, it heralded the beginning of the end for spam — as we knew spam back then, anyway. Applying a simple statistical approach, based on word frequency analysis with a naive Bayesian classifier, Graham described how to create a spam filter accurate enough (99+%) that false positives effectively ceased to be an issue.

The central idea of the Graham Algorithm was quickly adopted en masse by spam filters, and as a result, the spam arms race has in the past few years tipped in favor of the good guys. “Successful” spam has devolved into exactly what Graham predicted it would: “some completely neutral text followed by a URL.” For me personally, the combination of good server- and client-side filters has made spam yesterday’s problem. (Well, that, and using Gmail as a front-end for lower-priority e-mail; spam all you want, it’s Google’s problem and they’re up to the task.)

Recently at $WORK, we’ve succeeded in applying similar text classification principles to another unrelated problem area, with the intent of forcing the computer to do the tedious job it was invented for, allowing us super-apes, in turn, to spend more time under a palm tree on the nearby beach, sipping tinto de verano and working out answers to deep existential questions, or whatever else it is that one does on the beach (note to self: need more practice).

As part of a distributed, geographically load-balanced DNS daemon I’ve been developing in Scheme, I’ve put together a set of GeoIP API bindings for Chicken Scheme that I’m hereby making available under the MIT License.

This was the first egg I’ve developed for Chicken — not to mention the first time I’d needed to make any real use of Chicken’s FFI — and I have to say I was pleasantly surprised at how easy it was to create.

It was gratifying to be able to go from zero to completed egg in only a couple hours simply by looking at some other eggs for examples on how to use foreign-lambda , create a setup spec, and write the eggdoc documentation.

The GeoIP API subset provided by the egg is straightforward to use. Basically, you feed in a hostname or an IP address, and you get back a country code or country name. Country codes can be returned as either the 2-letter or 3-letter codes defined in ISO-3166-1.

Lately I’ve been familiarizing myself with Gambit-C. This has mostly been preparatory work in anticipation of the imminent release of Termite, Guillaume Germain distributed computing system inspired by Erlang and implemented using Gambit’s serializable continuations and lightweight processes, scalable up to millions of concurrent threads.

Gambit is definitely one of the more interesting Scheme implementations out there, not to mention among the fastest; its creator Marc Feeley has been described as a performance junkie, and according to the Gambit manual, “with appropriate declarations in the source code the executable programs generated by the compiler run roughly as fast as equivalent C programs.”

However, despite its technical excellence, Gambit doesn’t, as of yet, have much of a standard library.

Yesterday I needed to interface Gambit with MySQL, and couldn’t find any existing binding to let me do that (though an SQLite 2.x interface does exist). As I wasn’t familiar enough with Gambit’s FFI system, I took the über-simple, lazy man’s approach: I created a trivial wrapper API on top of the mysql and mysqladmin command line utilities.

Inspired by Common Lisp’s macroexpand-hook, here’s a pretty useful snippet I recently hacked together to assist me in debugging Scheme macros for Gauche :

(define-macro (define-macroexpand-hook hook)
  `((with-module gauche define-macro) (define-macro formals . body)
    (cond
      ((list? formals)
        `(define-macro ,(car formals)
          (lambda (,@(cdr formals)) ,@body)))
      ((symbol? formals)
        `((with-module gauche define-macro) ,formals
          (lambda args (apply ,',hook ,@body ',formals args))))
      (else
        (error "symbol required, but got" formals)))))

define-macroexpand-hook is a straightforward (well, not too hairy, anyway) macro-generating macro that overwrites the binding of the define-macro special form in the current module, with the result that any macros subsequently defined will include a call to a user-defined procedure (passed as the argument to define-macroexpand-hook), which will be invoked whenever the macro is applied.

(The immense power inherent in this brief code snippet will not, sadly, be something most programmers unfamiliar with Lisp can appreciate. What this is doing is essentially dynamically injecting additional code into the Scheme compiler itself — it’s not every language that lets you patch the compiler on the fly, while running.)