Daniel's Blog

Lisp Dialects

Posted by Daniel Lyons Tue, 05 Feb 2008 04:35:00 GMT

“Lisp was not the product of a concerted design effort. Instead, it evolved informally in an experimental manner in response to users’ needs and to pragmatic implementation considerations. Lisp’s informal evolution has continued through the years, and the community of Lisp users has traditionally resisted attempts to promulgate any “official” definition of the language.”—Structure and Interpretation of Computer Programs, Abelson and Sussman, page 3.

The rocking sensation you probably did not feel a couple weeks ago was the release of Paul Graham’s Arc. Many people made many remarks about Arc being a massive letdown. I must admit I shared the sense of disappointment. After so many years of promises, and reading and respecting Paul Graham, and then, almost nothing, a tiny language atop a tiny Scheme. It hardly seems like anything to get worked up about.

The Lisp world is an interesting place these days. By and large, people have an opinion about Lisp based on experiences with Common Lisp and Scheme, which I think account for the vast majority of Lisp users. Yet, as Abelson and Sussman observe above, there never really was a Lisp consensus in the past, and today there are far more interesting variants of Lisp in the wild with few users. I think we expected Arc to represent a turning point in Lisp’s evolution towards a more Pythonic development model, the benevolent dictator, with a programming language aesthete in the driver’s seat. There are two important lessons here.

The first lesson is that we do not need Paul Graham to tell us what makes a compelling Lisp. We can mix-and-match our own stuff. Consider SRFI 26, Notation of Specializing Parameters without Currying:

(map (cut * 2 <>) '(1 2 3 4))

That’s almost as compact as this (hypothetical and untested) Arc code:

(map [* 2 _] '(1 2 3 4))

And of course it would be possible to create a reader macro for many Schemes which would achieve the same trick. But the SRFI-26 syntax also permits arbitrarily nested expressions with arbitrarily many variables—does Arc?

This SRFI has been around for six years and is supported by PLT (DrScheme), Kawa, Guile, Chicken, SISC and Gauche implementations, which is most of the ones you’d ever care to use.

Swindle has been around an equally astonishing amount of time, and is nothing but a bunch of Scheme sources that go atop any old Scheme (though bundled with DrScheme). And that gives you damn near 100% CLOS compatibility, based in part on Tiny-CLOS which is also very portable.

This is just what I’ve been looking at lately. There are a ton of compelling Lisps out there, far more fascinating than Arc; in addition to the ones I mentioned last time there’s also Nu, L# and Clojure.

My advice to you: do what Paul has done. Evolve your own Lisp. Pick Lisp or Scheme as your basis if you want to be able to share, or another language if you want to exploit some power it has. Try to keep your modifications portable or use a portable starting basis. Publish your changes.

The second lesson is, of course, to not be disappointed in Arc. We’re disappointed in Arc because we were expecting something “better” than Lisp, or something other than Lisp. Paul delivers a pile of macros. Well, that’s all you’re ever going to get with Lisp. It’s only a let down because we were expecting some kind of magic. But Paul doesn’t have a monopoly on this magic, we all have it. That’s part of the beauty of Lisp. Maybe it’s a disappointment that Paul really can’t do any better than we can, but remember it also means we can do as well as Paul.