From: Richard Lynch
Subject: Matching Parens (was Virtues of LISP Syntax?)
Date:
Message-ID: <12558@accuvax.nwu.edu>
I can read LISP code just fine if "standard" parenthesis rules are used.
BUT, when it comes to debugging code known to be faulty, I really hate to try
and figure out which parenthesis the ones at the end of a line are coding.
And it's not enough to assume that the code is lined up correctly (even by
the editors that supposedly line it up for you.)
That's why I always follow these rules:
A closing parenthesis can only appear:
A. In the same line as the open parenthesis.
B. In the same column as the open parenthesis.
The indentation for arguments on lines below the function is 2 spaces. Always.
Thus, my code looks like this:
(defun insert-menu (menu &optional (place nil))
"Inserts menu at place in the menubar. If place is a menu, the new menu goes
after it. If place is an integer, the menu goes in that ordinal position."
(let ((need-update (installed-p)))
(if place
(let* ((old-menus (menus))
(len (length old-menus))
)
(when (isa-p place *menu*)
(let ((pos (position place old-menus)))
(if pos
(setq place (1+ pos))
(setq place (1+ len))
) ) )
(if (integerp place)
(progn
(setq place (max 0 place))
(setq place (min place (1+ len)))
(if (= place (1+ len))
(add-menu menu)
(set-menus (nconc (subseq old-menus 0 place)
(list menu)
(subseq old-menus place len)
) ) ) )
(cerror "Adding ~S to end of menubar..."
"Invalid place specifier ~S for insert-menu.~%~
place must be an integer or menu." place
(add-menu menu)
)
) )
(add-menu menu)
)
(if need-update (set-menubar (menus)))
) )
Actually, before you flame me, I am aware that on lines that have just
right parens, they are in reverse order and thus my rules are incorrectly
stated. But I consider them "isomorphic" in some sense.
I hardly ever have parenthesis problems, and when I do, I find the error very
quickly.
The expense of a lot of lines with just right parens is worth the benifit of
minimal debugging time to me.
Anyone else use this, or am I all alone here?
"TANSTAAFL" Rich ·····@aristotle.ils.nwu.edu
·····@aristotle.ils.nwu.edu (Richard Lynch) writes:
> .... [Suggested indentation rules] ....
> A. In the same line as the open parenthesis.
> B. In the same column as the open parenthesis.
> .... [Example deleted] ....
First, a comment: any decent editor (e.g. Zmacs) will negate (certainly
severly lessen) the need for this sort of thing. *However*, I do realize
that among our brethren and sistern are poor souls caught in the bowels of
*NIX and other such precambrian systems where, through no sin of their own,
such contortions are necessary.
That off my chest, I would only make one suggestion: that you change Rule B
to read:
> B. In the same column plus one as the open parenthesis.
For example
(YU-SHIANG-KITTY
ARG-1
ARG-2
)
Among the reasons for this are:
o It avoids having a close parentesis in the first column, which can
potentially screw up the way some editors do things like count number
of forms in a buffer, etc. (Indeed it is typically A GOOD THING not to
have anything in the first column except the opening paren of a top
level form or a comment.)
o It "indicate" where a next argument would go --i.e. you wouldn't line
the args up with opening parentheses.
o Among code that I've seen, this seems to be more standard than your
Rule B.
Cheers
NICHAEL
·······@bbn.com -- Forward Quarter Guard and Captain, BBN Calvin Ball Team.
From: Steve Strassmann
Subject: Re: Matching Parens (was Virtues of LISP Syntax?)
Date:
Message-ID: <3474@media-lab.MEDIA.MIT.EDU>
From: ·····@aristotle.ils.nwu.edu (Richard Lynch)
Newsgroups: comp.lang.lisp
Date: 25 Sep 90 22:15:43 GMT
I can read LISP code just fine if "standard" parenthesis rules are used.
BUT, when it comes to debugging code known to be faulty, I really
hate to try and figure out which parenthesis the ones at the end of
a line are coding.
The expense of a lot of lines with just right parens is worth the
benifit of minimal debugging time to me. Anyone else use this, or am
I all alone here?
Nothing personal, but I hope you're all alone. If people paid half as
much attention to their user interface as they did to their compilers,
we wouldn't have to deal with silliness like this.
Perhaps you should be using an editor like emacs that comes with some
smarts about traditional lisp formatting. For me at least, the
indentation of the immediately following line tells me all I need to
know about any close-parens.
For example, in lisp-mode in many versions of emacs, <tab> indents a
given line, and <C-M-q> indents a given s-expression. Typing a close
parenthesis blinks the corresponding open parenthesis. <C-M-f> and
<C-M-b> take you back and forth over a given s-expression so you can
see its beginning and end.
From: Mikel Evins
Subject: Re: Matching Parens (was Virtues of LISP Syntax?)
Date:
Message-ID: <45188@apple.Apple.COM>
In article <····@media-lab.MEDIA.MIT.EDU> ·····@media-lab.MEDIA.MIT.EDU (Steve Strassmann) writes:
>
>For example, in lisp-mode in many versions of emacs, <tab> indents a
>given line, and <C-M-q> indents a given s-expression. Typing a close
>parenthesis blinks the corresponding open parenthesis. <C-M-f> and
><C-M-b> take you back and forth over a given s-expression so you can
>see its beginning and end.
For this kind of thing I like the EMACS-oid editor in Macintosh Allegro
Common Lisp even better. Like the usual Lisp-mode EMACS, Fred (the
Emacs in MACL) reindents when you type tab. Placing the text insertion
point next to a parenthesis starts the matching paren blinking, and
it just keeps doing it, so not only do you see where it is, you keep
seeing where it is (you don't forget that way; I don't know about
other people, but my short-term memory fails me with reference to this
kind of detail sometimes). By the way, the blinking is done by alternately
making the paren visible and invisible, rather than by blinking a
block cursor or something, so it's not visually obnoxious. Double-clicking
the mouse button while the pointer is next to a paren selects the entire
expression, displaying it in reverse video. Hitting tab then reindents
the selected text.
Little things like this can make a huge difference in the convenience
of a programming environment.
--me
From: Daniel Choy Edelson
Subject: Re: Matching Parens (was Virtues of LISP Syntax?)
Date:
Message-ID: <1950@anaxagoras.ils.nwu.edu>
In article <·····@accuvax.nwu.edu> ·····@aristotle.ils.nwu.edu (Richard Lynch) writes:
>That's why I always follow these rules:
>
>A closing parenthesis can only appear:
> A. In the same line as the open parenthesis.
> B. In the same column as the open parenthesis.
>
>The expense of a lot of lines with just right parens is worth the benifit of
>minimal debugging time to me.
>"TANSTAAFL" Rich ·····@aristotle.ils.nwu.edu
I've thought about this for a while, and I can't see any benefit to
it.
It doesn't help you debug, because if there's a parenthesis problem
then you can't count any of the parens being in the correct column
anymore, and you have to go to the same trouble as normal to find
which right paren is missing.
As others have pointed out, I can't see how it helps at coding time,
because the formatters and electric-paren features of emacs-like code
show you which paren you're matching without you needing to space over
to the appropriate column.
Most important, I think that an experienced lisp programmer spends
very little time debugging parenthesis errors, no matter where he or
she puts the right parens and that the time and space spent in
following these rules is time lost not gained.
I think that a novice lisp programmer would be better served in
learning to use formatters and paren balancers than in taking time to
learn rules like these.
--
---------
Danny Edelson Institute for the Learning Sciences
·······@ils.nwu.edu Northwestern University
(708) 491-3500 Evanston, IL 60201
Pardon me while I pick a few nits:
·····@aristotle.ils.nwu.edu (Richard Lynch) writes:
>That's why I always follow these rules:
...
>The indentation for arguments on lines below the function is 2
>spaces. Always.
>
>Thus, my code looks like this:
...
> (let* ((old-menus (menus))
> (len (length old-menus))
> )
...
> (cerror "Adding ~S to end of menubar..."
> "Invalid place specifier ~S for insert-menu.~%~
> place must be an integer or menu." place
> (add-menu menu)
> )
...
>"TANSTAAFL" Rich ·····@aristotle.ils.nwu.edu
--
John Burger ····@mitre.org
"You ever think about .signature files? I mean, do we really need them?"
- alt.andy.rooney