4

I'm currently learning Lisp, and I think that I got the basics (I'm using the excellent book Land of Lisp, and so far I've read and worked through about a quarter).

I try to create my own Lisp programs, based on what I already learned. Somehow, it works. But it's only somehow. So far I have been developing mainly in languages with C syntax, such as C# and JavaScript (and please note that I'm perfectly aware that JavaScript is not a C-based language).

Nevertheless, I'm used to "think" in C syntax, and when I write code in C# or JavaScript, I can write it down in a quite straightforward way. In contrast, when writing Lisp code I have enormous difficulties wrapping my mind around all those parentheses.

If I have a simple statement such as

(setf x (+ 2 3))

I always find myself in trying to read it from left to right, find out that it does not work, then search for the innermost pair of parentheses, and then work it out inside-out. For this simple expression, this works quite fast.

But if I have more complex code (although it is not yet complex at all), say a function that uses let, it's harder (at least for me) to find the innermost pair of parentheses:

(defun foo ()
  (let ((x 23)
        (y 42))
  (+ x y)))

Here it's already a little bit harder to see what happens after what, and what is nested to what. Now add some cond stuff, perhaps combined with a few lambdas, and I'm perfectly lost and find myself counting parentheses for minutes (literally).

The same is true when writing it, I get lost in the number of parentheses, and I don't think that I even saw "complex" Lisp code yet.

Does this get better over time? I.e., do you get used to it? Or, are there tricks on how to approach reading and writing Lisp code to make things more easy for yourself? How do more experienced Lisp programmers do this? Any hints?

Golo Roden
  • 140,679
  • 96
  • 298
  • 425
  • 6
    Use an editor that automatically indents the code, such as Emacs, so the structure becomes visible. E.g. in your last example, `(+ x y)` should be indented two more spaces, so you can see that it's the body of the `let`. – Barmar May 29 '14 at 06:11
  • Hm, okay. That helps with writing, but what about reading? E.g., when I read code on StackOverflow ;-)? – Golo Roden May 29 '14 at 06:13
  • 4
    Once the code is indented properly, you can almost ignore the parentheses. In time you'll get used to the common idioms like `defun` and `let`. – Barmar May 29 '14 at 06:14
  • What's the difference if the code is on SO? If it's not indented well, it's hard to understand; if it's indented properly, it's readable. I spend half my time on SO editing people's posts in many languages to fix the indentation so they're readable. – Barmar May 29 '14 at 06:15
  • 1
    Just installed [lispindent](https://github.com/odyssomay/sublime-lispindent) for Sublime, and in fact, just having auto-indentation really helps. Amazing :-). Thanks for the hint! – Golo Roden May 29 '14 at 06:17
  • 1
    You are right. Javascript, c#, java, perl, c++ and c++ are all Algol dialects. It's easy to read since you know the syntax of Algol. Common lisp and Scheme are Lisp dialects and it's easy to read them if you know one of them. – Sylwester May 29 '14 at 11:07

2 Answers2

10

You need to indent it properly. Your example is not.

(defun foo ()
  (let ((x 23)
        (y 42))
  (+ x y)))

Here:

(defun foo ()
  (let ((x 23)
        (y 42))
    (+ x y)))

The last expression needs to be shifted to the right. Then you can see that it is inside the LET.

Lisp has a few structure patterns. Not too many. Once you learn and training those, reading Lisp is relatively easy. Much less hard than learning Chinese which is read by a lot more people.

some patterns:

(symbol ...)

the symbol gives the anchor

((a 10) (b 20))

binding list, for example in LET

(with-foo (foo :option1 1 :option2 2)
  (body))

Macros like WITH-OPEN-FILE.

Then the complex function arglist itself. Positional args, optional args, keyword args. &rest and &aux.

There are a few more, but not too many. Once you have learned the basic macro and special form patterns, code reading gets much easier.

How to improve that? Read code. Train. It's not really difficult. A little bit like bicycle riding. First days seem to be difficult, then it's automated.

Writing.

To write code, you need an editor which can indent. Most can only indent lines, but can't format whole expressions. Thus you need to do the formatting. There are a few basic rules. Lisp has a pretty printer, which can format. But that's often not usable inside the editor and it does not know about things like comments.

When I write a piece of Lisp code, I usually spend also a bit of time for the proper layout of the code.

  • Lines too long?
  • Dangling parentheses?
  • Correct structure?
  • Alignments?
  • Enough visual clues?
  • Naming?
  • Comments?
  • Documentation?
Rainer Joswig
  • 136,269
  • 10
  • 221
  • 346
  • Extremely useful answer (as all of your answers I've read so far)! Thanks for doing such great work on SO :-)) – Golo Roden May 29 '14 at 16:48
  • 1
    Now that ten days are gone, and I have read and written some Lisp code yet, I have to say that all those parentheses are *lot* less harmful than what I would have expected in the beginning. It's true: If you indent properly, after a few days you stop counting `(`s and `)`s and instead start to see the actual structure of the code. Just wanted to add that as it may be helpful for other starters :-) – Golo Roden Jun 08 '14 at 11:12
  • 1
    @GoloRoden: Adoption: Fear of parentheses, first training, 1(defun 2(foo)2 2(arg)2 2(sin 3(+ arg 2)3)2)1 , (defun foo (arg) (sin (+ arg 2))), defun foo arg sin(+ arg 2) , (defun foo (arg) (sin (+ arg 2))) ... the you find PAREDIT and after a while you find actual uses for the parentheses, ... – Rainer Joswig Jun 08 '14 at 11:33
4

I am new to Lisp as well. However, I find it relatively easy to learn.

IMO the main thing to keep in mind is that Lisp is a direct representation of the Abstract Syntax Tree. Where other languages are text-oriented, and their syntax is modeled to be nearer to human language, Lisp is tree-oriented. Thus it needs a completely different way of reading and writing. If you're counting parentheses, you're doing it wrong.

You should learn to read lisp code as a tree. With a correct indenter, it will automatically be represented as such, with the first token of an s-expression representing the root of any subtree. The layout thus resembles the layout in a tree view, e.g. the left side in Windows Explorer.

Perhaps it is easier for me, as I have written analysis software that worked directly on the AST of C/C++ code. I remember back then the step from knowing the source to understanding the AST was not easy and I kept making mistakes that I could have avoided if I had thought about the AST, instead of always thinking about the source code.

For this reason I recommend ParEdit for emacs for writing code. ParEdit stops you from writing Lisp code as text, and instead allows (or forces, however you want to call it) you to write and transform the AST directly.

Flash
  • 107
  • 8