Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Lisp Parentheses

People also ask

Does anyone still use LISP?

LISP. One of the old languages, LISP, has lost its fame and started its journey to death. The language is being rarely used by developers these days.

Is LISP a high level language?

Lisp (historically LISP) is a family of programming languages with a long history and a distinctive, fully parenthesized prefix notation. Originally specified in 1958, Lisp is the second-oldest high-level programming language still in common use.

Is LISP used in 2021?

In 2021, this is an argument both for and against Lisp: Lisp implementations are sufficiently fast, so Lisp is best. Modern languages are powerful, so they are best.

Is LISP better than C++?

Our results suggest that Lisp is superior to Java and comparable to C++ in terms of runtime, and superior to both in terms of programming effort, and variability of results.


LISP IDE environments tend to balance parentheses automatically and manage indents based on nesting level. Sample 2 does not bring any advantages in those situations.

In the C/FORTRAN/Pascal heritage, you tend to emphasize sequencing over nesting (code parse trees are shallower and wider). End of scope is a more significant event in your code: hence emphasis has been and still to some extent is more important.


For experienced Lisp users, the nesting level is more important than finding closing parentheses. Putting closing parentheses on their own lines does not really help with nesting levels.

The basic idea is that the parentheses are directly AROUND their contents.

(a)

and not

(a
)

What follows is this:

(defun foo (bar)
  (foo (bar (baz
              ...
             )
         ...
        )
    ...
   )
 )

vs.

(defun foo (bar)
  (foo (bar (baz ...) ...) ...))

One of the basic ideas when editing Lisp text is, that you can select a list by (double-) clicking on the parentheses (or by using a key command when the cursor is inside the expression or on the parentheses). Then you can cut/copy the expression and paste it into another position in some other function. Next step is to select the other function and re-indent the function. Done. There is no need to remove or introduce new lines for for closing parentheses. Just paste and re-indent. It just fits in. Otherwise you would either waste time formatting the code, or you would need to re-format the code with some editor tool (so that closing parentheses are on their own lines. Most of the time it that would create additional work and hinders moving code around.

There is one occasion where experienced Lispers would sometime write closing parentheses on their own line:

(defvar *persons*
   (list (make-person "fred")
         (make-person "jane")
         (make-person "susan")
         ))

Here it indicates that new persons can be added. Place the cursor directly before the second closing parentheses on the last line, press c-o (open line), add the clause and indent the parentheses that they are aligned again. This saves the 'trouble' to find the right parentheses and then press return, when all parentheses are closed on one line.


Because there is no need whatsoever to line up closing parens. It doesn't add anything semantically. To know how many to close, most Lispers use a good editor, such as Emacs, that matches parens to closing parens and hence makes the task trivial.

In Python, there are no closing parens or end keywords at all, and Pythonistas live just fine.


After a while with Lisp you don't notice the parentheses any longer, so your example two comes across as having a bunch of unnecessary whitespace in the end of it. More specifically, most lispers use an editor that is aware of parentheses and takes care of closing the forms correctly, so you as the developer don't need to match opening and closing parentheses like you do in e.g. C.

As for whether the last form should be

(* n (factorial (- n 1)))

or

(* n
   (factorial (- n 1)))

that mostly comes down to personal preference and how much stuff is going on in the code (In this case I'd prefer the former just because there is so little happening in the code).