Common Lisp: First Impressions

I went to my Alma Mater’s library in search of a book on Common Lisp and found Paradigms of Artificial Intelligence: Case Studies in Common Lisp by Peter Norvig. The book is 946 pages long and covers both AI and Common Lisp in depth. I started working through the Common Lisp chapter and found that it is much richer in features than I expected. I’ve always heard that Common Lisp is quite a contrast to Scheme, but hearing isn’t the same as experiencing it.

One thing that I like about Python is the cleverly designed def (define function) syntax, which gives the programmer all kinds of convenience and flexibility in defining functions (for example, having an arbitrary number of arguments, having explicitly named arguments, or having a combination of positional and explicitly named arguments — details here). Common Lisp has clever function-defining syntax too. Here’s an example of declaring a function with three explicitly named parameters, one of which is optional:

> (defun foo (bar &key (baz 30)) (list bar baz)
FOO
> (foo 30)
(30 30)
> (foo 30 :baz 90)
(30 90)

Another thing Common Lisp has in common with Python is doc-strings. I’ve seen them in emacs before. A doc-string is a piece of documentation that can be put in the function declaration and accessed at run time (or from within the REPL). In both Python and Common Lisp the doc-string goes in between the argument list and the function body.

One cool thing about Ruby is the ability to call a method with a minimal number of keystrokes. If bar has a method named baz with 0 parameters, the code to call it is “bar.baz”. There’s no need for empty parenthesis! In Python “bar.baz” would refer to the method itself. In ruby, to refer to the method itself, it’s “bar#baz”.

Common Lisp uses a hash symbol to refer to a function, but it is for a different reason. Common Lisp, like elisp (Emacs’ built-in scripting language), has a separate namespace for functions and variables. It’s possible (but arguably bad style) to have functions and variables with the same name. To refer to the functions, you add a hash and a single quote before them (e. g. #’foo).

It looks as though Python and Ruby both have inherited from Common Lisp. And that shouldn’t be a surprise – the designers of Python and Ruby have been programming long enough to remember a time when Lisp was more popular.

One thing about Common Lisp that’s often cited when someone mentions how big it is compared to Scheme is the format function. The format function practically has its own language for printing out text, and as Norvig notes, it’s not a very Lisp-like language. But there is also the loop macro, which was given its own chapter in Common Lisp the Language, 2nd Edition.

While I might just skip over learning to use the loop macro, I think that there are a lot of really cool functions and macros in Common Lisp that you could do without, but make things more convenient. It has some things that might seem redundant, but that can be used to code more clearly what you are trying to do. For example, there is a when macro, which is like if, but without the else clause. A Common Lisp programmer that comes upon “when” knows not to expect the else clause.

Another neat thing about Common Lisp implementations in general is that there tends to be debugging and optimization support accessible from the REPL (read-eval-print loop).

My first impression is that when I use Common Lisp, it feels like a mature language. I can tell why Norvig chose it to do lots of AI projects. It has a lot of features people want — it “lets hackers have their way with it” [1]. It’s multi-paradigm. Scheme is a little too focused on one paradigm (functional programming) for my tastes.

[1] Paul Graham‘s essay The Dream Language, form Hackers & Painters, which is not available online (yet). In my opinion, it’s one of his best essays.