Irreal

A while ago in Lexical Scoping In Emacs Lisp I wrote that Emacs 24 will (finally) introduce lexical binding. Trawling through the EmacsWiki today I came across a page, Dynamic Binding Vs Lexical Binding, that describes the differences between the dynamic binding that Emacs Lisp currently has and the (optional) lexical binding that’s available in Emacs 24.

It’s a good introduction for Elisp programmers who aren’t familiar with lexical binding. It looks at the advantages of dynamic binding and lexical binding and when it’s appropriate to use each. The big win with lexical binding is that it allows us to write closures. There’s an example of a closure on the page but I’m not sure it really makes clear how big a win they can be.

Suppose you need some counters in your program. You’d like to be able to give them an initial value and then increment them by any amount. You could write something like this (given that you have lexical binding):

(defun make-counter (initial-count)
  (let ((count initial-count))
    (lambda (n) (setq count (+ count n)))))

A call to make-counter will return a counter that you can use to track some count. If you call make-counter several times, each counter will have a separate count field so they won’t interfere with each other.

That’s a very simple example, of course, but it’s easy to imagine more complicated examples. The astute reader will notice that the counter is actually a sort object (in the OO sense) that has a single method. It’s easy to provide additional functionality–displaying the count, for example–so that you could have an object with several methods (loosely speaking). This fact is one of the reasons that I don’t use eieio (or CLOS in CL) very much. I get most of the benefits with a simple closure.

In any event, if you are an Elisp programmer and confused about lexical versus dynamic binding, this page is an excellent introduction and well worth a read.

One of the links from the CategoryCode page that I wrote about yesterday is the Why Does Elisp Suck page. The idea is to give people a place to be grumpy about Elisp. My first thought was that, really, Elisp doesn’t suck—it’s a pretty nice language. I’d like to explore this question a bit more.

The answers to the “Why does Elisp suck?” question fall into two classes: the silly and the substantive. The silly answers are “because it’s not Scheme”, or “because it’s not Common Lisp”, or “because it’s not X” for your favorite language X. Are there better Lisps than Elisp? Of course. I’d argue that Scheme and Common Lisp are both better Lisps but that doesn’t mean Elisp sucks. If your X is something like Python or Ruby I’d wager that you aren’t really comfortable in Lisp but you’re certainly entitled to your opinion. On the other hand, preferring Python or Ruby or whatever also doesn’t mean Elisp sucks. In short, the fact that you’d rather code in a language other than Elisp doesn’t have very much to say about Elisp.

Of the substantive answers, only 3 are really of any concern to me. First and foremost is the lack of lexical scoping. That’s fixed (for certain values of fixed) in Emacs 24. The second problem is the lack of tail call elimination. Technically, Common Lisp doesn’t have this either—in the sense that it’s not in the standard—but as a practical matter all serious implementations of CL do eliminate tail calls. This matters to me because it enables a style of iteration that I prefer: see my rpl function for instance. Finally, there is no threading or concurrency. This bothers me less than the first two but it does mean that packages like gnus can slow things down.

Some of the other substantive problems with Elisp are no object system (a feature not a bug in my opinion), no module system (a pain because of name collisions but I can live with it), clumsy regular expressions (especially if what you really want are Perl regexps), and the API sucks.

Someone also noted that the Elisp implementation is slow. That’s true, I guess, but doesn’t really speak to whether or not Elisp sucks. It would be nice if things were snappier but on modern machines it seems fast enough to me. I’d guess that font locking and things like that have more to do with performance problems than the Lisp engine.

All-in-all, I find Elisp to be a comfortable language to write in. Not as powerful as Common Lisp and not as well designed as Scheme but still nice. What does everyone else think? Is Elisp something you put up with or do you like the language? I’d be surprised if very many people said it was their favorite language but I’d also be surprised if many Elisp users really do think the language sucks.

I’ve said before that Emacs Lisp is pretty much like any other Lisp except for its library, which is specialized for editing tasks. One of the things I like about Xah Lee’s Emacs Lisp Tutorial is that it doesn’t concern itself too much with Lisp itself but presents Elisp use cases and idioms. If you already know a little of any Lisp, then Xah’s tutorial is a good place to go to come up to speed with Elisp.

Today, I found another good resource: The CategoryCode page on the Emacs Wiki. They’ve got a long list of articles that show you how to do various tasks in Emacs Lisp. One page, the Elisp Cookbook, is particularly helpful. It contains a collection of code snippets for many common chores. Other articles are more specialized; they have, for example, an article on a Password Generator. Some of the articles are quite detailed while others merely describe a library that’s good for doing some task or another.

If you’re new to Elisp but have a basic knowledge of Lisp, I’d start with Xah Lee’s tutorial and then try some of the articles on the CategoryCode page. Of course, the definitive source is the GNU Emacs Lisp Reference Manual, which is also available in the built-in documentation. If you need to know the particulars about some function or slightly broader area, that’s the place to look but I don’t find it particularly useful for learning the ins and outs of Elisp. The other outstanding resource you have for that is Emacs itself. You might try reading simple.el, for example, to see how some of the simple editing functions are implemented. It will give you a good feel for Elisp idioms.