What is the reason Lisp code is not written with closing parens on new lines?
groups.google.comI highly recommend 'paredit' mode for any Lispers having trouble getting used to the parens.
It takes a few days for the shortcuts (http://www.emacswiki.org/emacs/PareditCheatsheet) to become second nature, but then you never really thinkabout the parentheses again.
If you use Vim and have "showmatch" enabled, then when you move your cursor onto a left or right parenthesis, it shows that character with a charcoal background, and the matching parenthesis with a teal background. Your mind immediately perceives the extent of the expression. Then if you press "%", your cursor moves to the matching parenthesis. You can toggle back and forth by pressing "%" repeatedly. This also works for braces and square brackets. Also you can delete, change, and yank whole expressions with the usual idioms "d%", "c%", and "y%".
I'm not arguing Vim over Emacs here, I just wanted to point out that Vim has excellent support for parenthesized expressions.
Interestingly, when I write procedural code such as C or Perl, I put a single brace on each line. For example:
if (condition)
{
...
}
That makes it easier for me to move whole blocks around.However, when I write functional code such as Lisp or Fexl, I tend not to do that. For example:
# Collect any matching entries at the front of the list.
\collect = (\match\list list end \head\tail
match head (item head (collect match tail)) end)
I think that's because I tend to keep all my Fexl expressions very short, building them up step by step.Also, Fexl uses ";" as a "right-pivot" operator. For example:
\collect = (\match\list list end \head\tail
match head (item head; collect match tail) end)
So in many cases I can avoid multiple right parentheses. The Clojure example in the article would become: \myfn-a = (\a\b zero? b a;
recur (afn (bfn (...)) a) (dec b))I tend to put them on new lines in a handful of cases. Defstructs are one, because then I can easily add a new field at the end by just inserting a new line and writing on it.
I write a fair amount of Scheme code. I don't like the one closing paren per line thing for a reason similar to why python and haskell choose indentation for grouping (try adding braces to them). Code written like that looks bigger than it really is and is quite tiring on my eyes.
I'm not sure if that long thread included my two favorite reasons before it turned flame-y:
1. Lisp has a lot more parens than C or Java has curly brackets. The cost to vertical space is exaggerated. Otherwise you end up closing in a new line sometimes and not others, which quickly becomes distracting.
2. Somebody once said (anybody have the quote?) that C and java code looks blocky, while lisp code looks more fluid, like clay being moulded. That aesthetic speaks to me.
I know I've read some seasoned Lisper insist that beyond a certain sized software project, good Lisp code will have fewer parentheses than good Java code has curly braces (owing supposedly to Lisp's potential conciseness). Of course, this could be an exaggeration or even a "no true Scotsman" argument. I haven't enough experience to know if the claim is plausible.
Java only uses braces to denote blocks, whilst Lisp uses parenthesis for everything. Contrast:
And:(if (= x 0) (foo x) (bar x))
The Lisp code has 8 parenthesis, whilst the Java code only has 4 braces. However, the Java code also has 6 parenthesis and 2 semicolons, so in total the Lisp code only has 8 control flow tokens, whilst the equivalent Java has 12 (or 13, if you count the 'else').if (x == 0) { foo(x); } else { bar(x); }That what I meant by "beyond a certain sized software project." The claim was that because Lisp can do a lot of things Java can't, Lisp will end up requiring such less code that it will have fewer parentheses than Java has curly braces. However, as another commenter mentioned, Lisp will surely have a higher parenthesis density than Java's curly brace density.
I don't know if that is literally true (I did spend quite a few years being paid to write Lisp, followed by quite a few years writing Java) but I think once you have been using Lisp for a while with a good environment the parentheses certainly feature a lot less in how you visualize the code.
I am also a Scot - if that helps ;-)
Yeah, I'm not sure, but for our purposes I just mean density. The typical line of lisp code may have 3 or 4 close-parens.
> Somebody once said (anybody have the quote?) that C and java code looks blocky, while lisp code looks more fluid.
This is from Paul Graham's book, On Lisp.
Indentation communicates most of what parenthesis do and therefore are mostly redundant as far as the (human) reader is concerned. Having them all bunched up at the end of the line is the most efficient way to (not have to) handle them. We can't get rid of them of course because although they aren't providing much benefit to the reader they are essential to the compiler/interpreter.
It is, if you feel like writing it that way.