Reading Lisp

Started by
7 comments, last by GameDev.net 17 years, 7 months ago
In my quest to learn more languages, I have begun taking a look at Lisp. I normally learn in three ways: 1) tutorials, 2) testing, 3) reading examples. My issue? All the examples I look at, I got lost so quick in the forest of parenthesis. Do you experienced Lisp programmers have any advice on how I can get used to looking at all the parenthesis and unwinding the meaning? I have experience with functional languages, but Lisp just confuses me. Thanks
Advertisement
Well, when you know what the functions are that you are looking at, it makes it a bit easier to read. So it will get better with time. Still, I prefer to do what most people don't and at least try to structure/format the code so that it is readable... and use comments...

; Check some condition here... blah blah blah(cond  ; If the first two list elements are equal, do whatever...  ; Otherwise, do whatever  ((eq (car l) (cadr l))         (somefunc-here some-arg))  (T                             (some-default-func-here some-arg)))


That sort of thing. A lot of people don't bother with superfluous whitespace.

EDIT: Fixed rogue parenthesis at end of cond.

[Edited by - smitty1276 on September 5, 2006 8:27:18 PM]
I think it is something that largely comes with exposure. It was for me.

Obviously, using an editor that highlights matching parentheses is a necessity.
Definately (what Brandon said) * 2. It's worth installing cygwin with xemacs for doing lisp.
Quote:
That sort of thing. A lot of people don't bother with superfluous whitespace.
I'm sure you mean well, but you clearly don't know what you're talking about.

Formatting lisp like that is a surefire way to:

1) Never be able to read any other lispers' code.

2) Guarantee no lisper will ever want to read yours.

There is a standard way of formatting lisp, with only minor deviations. Use it.

Quote:Do you experienced Lisp programmers have any advice on how I can get used to looking at all the parenthesis and unwinding the meaning?
I'm not an experienced lisp programmer, but I am halfways competent.

Lisp programmers read lisp by indentation.

There is a standard way to format lisp code; you read it by indentation and forget about the parentheses, much like python (oh the irony).

The editor you use should indent lisp code correctly. It should also show matching parentheses when you add or remove them. For example, if you use gvim, type (in command mode)

:set lisp
:set ai
:set showmatch

and suddenly writing lisp isn't that painful. :)

If you find yourself counting parentheses, stop and split things into a few lines.
Pay attention to the indenting, not the parentheses -- any lisp should be indented almost as stringently as Python.
Alright. That sure does help. Thanks guys.
Quote:Original post by Anonymous Poster
Formatting lisp like that is a surefire way to:
1) Never be able to read any other lispers' code.
2) Guarantee no lisper will ever want to read yours.

There is a standard way of formatting lisp, with only minor deviations. Use it.

I didn't claim to be a lisp expert. That's just how I like to format mine in the extremely rare cases that I must use lisp. But, now that you mention it, I would probably put the closing parenthesis at the end of the previous line, not on its own line. I'm not sure where that came from.

But whether the extra whitespace is normally used or not, I feel very strongly that formatting this way is inarguably superior. [grin] I would be interested in hearing an explanation of how NO formatting (aside from indentation) is easier to read.



Quote:I would be interested in hearing an explanation of how NO formatting (aside from indentation) is easier to read.


Properly indented lisp has a VERY distinctive structure. Lisp functions have distinctive shapes. This shape helps you understand what the code is doing. Comments destroy this shape.

I can stand across the room from my computer and look at my screen. Without reading the words (which I can't see) I can tell what a function is doing: I can tell where it is establishing bindings or context via context-creating macros.

I can tell where the conditionals are, and how branch-heavy that particular function is. Conds are very distinctive.

I can tell where a function's parameter list has been broken up into multiple lines, because it looks nothing like a binding construct, which in turn looks nothing like a conditional construct.

This structure lets me navigate through the code quickly. Comments just mess up a function's shape and thus leave me without this all-important visual guidance.

So I tend to write lisp in a literate programming style: loads of comment blocks with unpolluted code between them.

This topic is closed to new replies.

Advertisement