From: Leo Sarasua
Subject: Parentheses readability
Date:
Message-ID: <32068E3B.CD4@bart.nl>
Let's face it: all the ((((... and )))) in Lisp are awfully unreadable.
Despite having Lisp orientated editors, writing and reading a Lisp
program is sometimes an undaunting task because of the parentheses.
That's why I started long ago to use the following convention in my
programs: when closing parentheses I leave a blank between those ')'
parenthesis with a corresponding '(' in the same line and those whose
corresponding '(' is in a different line above. That way, it's simpler to
add and remove items (e.g. in a cond) and also to check where is
something wrong.
For instance, I would write:
(defun foo (a)
(cond ((atom a)
(print "An atom) )
(t (print (car a))
(foo (cdr a)) )))
I've been using this for quite a while now and it really helps. So my
question is: Is anyone using a similar convention or is there any
widespread method to improve lisp readability?
Actually, although your idea is a reasonable one, I don't find the
parens very confusing at all. In fact, since most of the time a lisp
programmer knows what s/he's reading by semantics, not syntax, the
parens are mostly for the compiler's sake. If I took your code and
rewrote it as:
: defun foo a
: cond atom a
: print "An atom"
: t print car a
: foo cdr a
Almost any lisp programmer would know exactly what was meant. Of
course, this isn't always the case, just as the commas in English
aren't *always* irrelevant. But putting much concern into the fact of
the matter lisp parens is a pastime that usually busys non-lisp
programmers who just don't know how to read lisp. (This is not to say
that you are among those poor unfortunates, but I doubt that you're
doing the lisp world much of a favor by introducing paren
conventions.)
Now, that said, I will mention that I occassionally do use ; comments to
notate the ends of long (usually, off the screen) paren matches, as:
(prog ...
<many lines of junk>
... ) ; close prog
This helps in finding what was closed if you don't happen to have M-cB
around. But for the most part, since I almost never look at code w/o
being in emacs, I almost never need such conventions.
Cheers,
'Jeff
In <············@bart.nl>, Leo Sarasua <········@bart.nl> writes:
|Let's face it: all the ((((... and )))) in Lisp are awfully unreadable.
|Despite having Lisp orientated editors, writing and reading a Lisp
|program is sometimes an undaunting task because of the parentheses.
|That's why I started long ago to use the following convention in my
|programs: when closing parentheses I leave a blank between those ')'
|parenthesis with a corresponding '(' in the same line and those whose
|corresponding '(' is in a different line above. That way, it's simpler to
|add and remove items (e.g. in a cond) and also to check where is
|something wrong.
|For instance, I would write:
|(defun foo (a)
| (cond ((atom a)
| (print "An atom) )
| (t (print (car a))
| (foo (cdr a)) )))
|
|I've been using this for quite a while now and it really helps. So my
|question is: Is anyone using a similar convention or is there any
|widespread method to improve lisp readability?
Interesting... I came upon the above solution a few years ago too. As I am
an AutoLisp infidel by profession, I also like to line up matching parens
sometimes.
HK
In article <············@bart.nl>, Leo Sarasua <········@bart.nl> writes:
>> Let's face it: all the ((((... and )))) in Lisp are awfully unreadable.
>> Despite having Lisp orientated editors, writing and reading a Lisp
>> program is sometimes an undaunting task because of the parentheses.
>> That's why I started long ago to use the following convention in my
>> programs: when closing parentheses I leave a blank between those ')'
>> parenthesis with a corresponding '(' in the same line and those whose
>> corresponding '(' is in a different line above. That way, it's simpler to
>> add and remove items (e.g. in a cond) and also to check where is
>> something wrong.
I agree Common Lisp has too many needless parens that just clutter
things up, and in particular: make it harder to edit the code.
I've changed my die-hard old-timer ways, and have become a loop convert,
and starting using a new syntax which I really think is better
and makes the language more accessible to "normal" people.
(defun paren-me-to-death (x y z)
(let* ((new (list x y)
(old (list z y z))
(save nil))
(do ((new1 new (rest new1))
(old1 old (rest old1)))
((null new1) save)
(cond ((eq (first new1) (first old1))
(print "eq")
(push new1 save)
((eq (first new1) 'bar)
(print 'bar)
(t (push old1 save)))))
I think that is too much non-syntax. We can afford a few syntactic markers
in lisp:
(defun paren-me-to-death (x y z)
(let new = (list x y)
old = (list x y z)
save = nil
do
(loop for new1 on new
for old1 on old
finally (return save)
do
(if (eq (first new1) (first old1))
then
(print "eq")
(push new1 save)
elseif (eq (first new1) 'bar)
then
(print 'bar)
else
(push old1 save)
))))
In article <··········@sparky.franz.com>, ···@franz.com wrote:
> In article <············@bart.nl>, Leo Sarasua <········@bart.nl> writes:
> >> Let's face it: all the ((((... and )))) in Lisp are awfully unreadable.
> >> Despite having Lisp orientated editors, writing and reading a Lisp
> >> program is sometimes an undaunting task because of the parentheses.
> >> That's why I started long ago to use the following convention in my
> >> programs: when closing parentheses I leave a blank between those ')'
> >> parenthesis with a corresponding '(' in the same line and those whose
> >> corresponding '(' is in a different line above. That way, it's simpler to
> >> add and remove items (e.g. in a cond) and also to check where is
> >> something wrong.
>
>
> I agree Common Lisp has too many needless parens that just clutter
> things up, and in particular: make it harder to edit the code.
People need the right tools for editing Lisp code, it
seems. Use color matching. Use an editor which barfs while saving files
for unbalanced parantheses, etc. Editing Lisp with Zmacs or Fred
is quite easy.
> I've changed my die-hard old-timer ways, and have become a loop convert,
> and starting using a new syntax which I really think is better
> and makes the language more accessible to "normal" people.
LOOP is really ugly. I'm using it a lot because
it has a lot of nice features and comes with the standard.
Otherwise I would strongly prefer the "ITERATE" macro, which
does everything "LOOP" does, does more and looks like Lisp.
Rainer Joswig
In article <············@bart.nl>, Leo Sarasua <········@bart.nl> writes:
> Let's face it: all the ((((... and )))) in Lisp are awfully unreadable.
> Despite having Lisp orientated editors, writing and reading a Lisp
> program is sometimes an undaunting task because of the parentheses.
> That's why I started long ago to use the following convention in my
> programs: when closing parentheses I leave a blank between those ')'
> parenthesis with a corresponding '(' in the same line and those whose
> corresponding '(' is in a different line above. That way, it's simpler to
> add and remove items (e.g. in a cond) and also to check where is
> something wrong.
Seasoned Lisp programmers see past parentheses just as a seasoned
reader of a printed language sees past the individual characters
comprising a word. Lisp code is read by shape, just as are words in
paragraph of text (cover up the the bottom half of a sentence and
notice how this barely affects your ability to quickly read it).
To correctly sculpt your Lisp code into a beautiful shape you need
an editor that understands Lisp indentation conventions, e.g. most
versions of Emacs. If you are twiddling parentheses then you are
sculpting with prehistoric tools. A good Lisp editor provides tools
that work on the algebraic tree structure of s-expressions (note
the fact that Lisp has such a trivial syntax greatly simplifies the
implementation of editor utilites for true syntax-based manipulation
of code fragments; ditto for code decoration: coloring, fontification,
etc).
It will take some effort to truly understand the Lisp philosophy,
but once you master the basics and begin sculpting masterpieces
you will never look back.
Happy sculpting,
-Bill
From: Ken Tilton
Subject: Re: Parentheses readability
Date:
Message-ID: <320FA197.147E@bway.net>
Bill Dubuque wrote:
>
> In article <············@bart.nl>, Leo Sarasua <········@bart.nl> writes:
>
> > Let's face it: all the ((((... and )))) in Lisp are awfully unreadable.
>
> Seasoned Lisp programmers see past parentheses just as a seasoned
> reader of a printed language sees past the individual characters
> comprising a word.
Parentheses? What parentheses? <g> Like you say, I stopped seeing them
after about a week of serious Lisp.
But they really drive me crazy now when I have to use them in VAX Basic,
since the VAX editor I use does not have any features simplifying the
editing of parentheses.
My retort to "what about all those parentheses?" is "do spaces between
words bother you?". <g>
Leo Sarasua <········@bart.nl> wrote:
>Let's face it: all the ((((... and )))) in Lisp are awfully unreadable.
>Despite having Lisp orientated editors, writing and reading a Lisp
>program is sometimes an undaunting task because of the parentheses.
>That's why I started long ago to use the following convention in my
>programs: when closing parentheses I leave a blank between those ')'
>parenthesis with a corresponding '(' in the same line and those whose
>corresponding '(' is in a different line above. That way, it's simpler to
>add and remove items (e.g. in a cond) and also to check where is
>something wrong.
>For instance, I would write:
>(defun foo (a)
> (cond ((atom a)
> (print "An atom) )
You should have closed your string.
> (t (print (car a))
> (foo (cdr a)) )))
>I've been using this for quite a while now and it really helps. So my
>question is: Is anyone using a similar convention or is there any
>widespread method to improve lisp readability?
Your method does improve readability slightly.
I just use the tab key on Emacs to prettyprint, and use Emacs to count
(the bra winks when you type the ket). If I don't have an Emacs, I
just count them open and then count them closed. If I end up with
zero, the parentheses are balanced.
I personally don't mind the parentheses, but if you don't like them
you can always write a read macro to avoid typing them in. Depending
on how you code your read macro, you could end up with the sort of
syntax you get in functional languages such as Haskell.
Le Hibou ·····@enterprise.net http://homepages.enterprise.net/hibou/
There are a number of mechanical devices which increase sexual
arousal, particularly in women. Chief among them is the
Mercedes-Benz 380SL convertible. -- PJ O'Rourke.
Leo Sarasua (········@bart.nl) wrote:
: For instance, I would write:
: (defun foo (a)
: (cond ((atom a)
: (print "An atom) )
: (t (print (car a))
: (foo (cdr a)) )))
: question is: Is anyone using a similar convention or is there any
: widespread method to improve lisp readability?
My job involves converting old C code into a 4gl. We developed coding
standards for the programmers which I applied (very nicely, I think) to
my LISP class. In brief, I used to above procedure, starting and finishing
a list on one line, then carried closing parenthesis' to the next line and
adding closing comments.
For example, let me re-write your function:
(defun foo (a)
(cond ((atom a) (print "An atom"))
(T (print (car a)) (foo (cdr a)))
) ;;; end COND
) ;;; end function foo
It makes for longer source listings but improves readability and finding
mis-matched parenthesis', especially for long CONDs, IFs, LOOPs, etc..
Side-bar:
One of the grad students in the class coined a new acronym for LISP -
Lost In Several Parenthesis
Jeff
--
* internet--> ········@pitt.edu * This space reserved *
* http://www.pitt.edu/~jesst63 * for something much *
* "I am outcast, unclean." - Thomas Covenant * better to come along *
: My job involves converting old C code into a 4gl. We developed coding
: standards for the programmers which I applied (very nicely, I think) to
: my LISP class.
I, and perhaps others on the list, would be interested in seeing these
if they are in a postable form.
: ) ;;; end COND
: ) ;;; end function foo
(Note that the MIT quasi-standard for comments uses a single colon at
the end of lines (three for block comments, two for inter-fn sectional
comments.)
: Side-bar:
: One of the grad students in the class coined a new acronym for LISP -
: Lost In Several Parenthesis
The version I quote for this (although I don't believe it myself) is
"Lots of Irritating Strongs of Parens." :)
Cheers,
'Jeff
p.s., Can anyone explain why the, um, I'm looking for a nice word to
describe the designers of C++, anyway.... why they didn't fix the
problem of having un-nestable comments, as the #|...|# in lisp will
nest. As a result of have unnestable commenting, you can't use
comments to comment out segments of code, which is among the most
powerful testing and revision tools. Do C programmers simply not
debug or something? I wouldn't be too surprised, actually. (For
those who have never tried to program in C/C++ (more power to you!),
if you go:
/* I don't want this piece of code to run...
some random code
that you don't want /* This line has an internal comment */
to run
*/
The middle */ closes the opening /* !!!
I'd rather use LISP than C++, of course, but still, a C++ programmer wouldn't
do the comment nesting like you do below. They (actually, "we" :-) do debug
by commenting out blocks of code, but they use #if instead. I.e.,
#if 0
some random code
that you don't want /* This line has an internal comment */
to run
#endif
Works great, and it nests, too. Anyway, sorry to intrude, but this was just
a bit of a strawman, and C/C++ has enough problems that we don't need to make
up some more for them :-)
Having said that, yes, I do miss #| ... |# :-(
Cheers,
Ruben
·······@neurocog.lrdc.pitt.edu (Jeff Shrager) writes:
>
> p.s., Can anyone explain why the, um, I'm looking for a nice word to
> describe the designers of C++, anyway.... why they didn't fix the
> problem of having un-nestable comments, as the #|...|# in lisp will
> nest. As a result of have unnestable commenting, you can't use
> comments to comment out segments of code, which is among the most
> powerful testing and revision tools. Do C programmers simply not
> debug or something? I wouldn't be too surprised, actually. (For
> those who have never tried to program in C/C++ (more power to you!),
> if you go:
>
> /* I don't want this piece of code to run...
> some random code
> that you don't want /* This line has an internal comment */
> to run
> */
>
> The middle */ closes the opening /* !!!
--
Ruben A. Gamboa, Technical Fellow | Phone: (512) 346-5464 x24
LIM International | Fax: (512) 346-5386
9390 Research Blvd., Kaleido II, #200 | Email: ·····@lim.com
Austin, TX 78759
In article <··········@usenet.srv.cis.pitt.edu> ········@pitt.edu (Jeffrey E Stoner) writes:
>
> Leo Sarasua (········@bart.nl) wrote:
> : For instance, I would write:
> : (defun foo (a)
> : (cond ((atom a)
> : (print "An atom) )
> : (t (print (car a))
> : (foo (cdr a)) )))
>
> : question is: Is anyone using a similar convention or is there any
> : widespread method to improve lisp readability?
>
> My job involves converting old C code into a 4gl. We developed coding
> standards for the programmers which I applied (very nicely, I think) to
> my LISP class. In brief, I used to above procedure, starting and finishing
> a list on one line, then carried closing parenthesis' to the next line and
> adding closing comments.
>
> For example, let me re-write your function:
>
> (defun foo (a)
> (cond ((atom a) (print "An atom"))
> (T (print (car a)) (foo (cdr a)))
> ) ;;; end COND
> ) ;;; end function foo
>
> It makes for longer source listings but improves readability and finding
> mis-matched parenthesis', especially for long CONDs, IFs, LOOPs, etc..
>
All of you who are making these suggestions need to study and use Emacs
s-expression operations for awhile and then re-think your suggestions.
There is really no need for these kinds of conventions for on line code if
modern tools are used. And for hardcopy Lisp code as long as it is indented
properly why do you care about closing parentheses?
--
William P. Vrotney - ·······@netcom.com
In article <··········@usenet.srv.cis.pitt.edu> ·······@neurocog.lrdc.pitt.edu (Jeff Shrager) writes:
p.s., Can anyone explain why the, um, I'm looking for a nice word to
describe the designers of C++, anyway.... why they didn't fix the
problem of having un-nestable comments, as the #|...|# in lisp will
nest. As a result of have unnestable commenting, you can't use
comments to comment out segments of code, which is among the most
powerful testing and revision tools. Do C programmers simply not
debug or something? I wouldn't be too surprised, actually. (For
those who have never tried to program in C/C++ (more power to you!),
if you go:
/* I don't want this piece of code to run...
some random code
that you don't want /* This line has an internal comment */
to run
*/
The middle */ closes the opening /* !!!
You can still do
#if 0
some random code
that you don't want /* This line has an internal comment */
to run
#endif
Rolf-Thomas
In article <··············@xtreme.mathematik.uni-freiburg.de> ·······@xtreme.mathematik.uni-freiburg.de (Rolf-Thomas Happe) writes:
From: ·······@xtreme.mathematik.uni-freiburg.de (Rolf-Thomas Happe)
Newsgroups: comp.lang.lisp
Date: 08 Aug 1996 23:53:18 +0200
Organization: Inst Appl Math, Freiburg University
Lines: 30
Sender: ·······@xtreme.mathematik.uni-freiburg.de
References: <············@bart.nl> <··········@usenet.srv.cis.pitt.edu>
<··········@usenet.srv.cis.pitt.edu>
X-Newsreader: Gnus v5.1
In article <··········@usenet.srv.cis.pitt.edu> ·······@neurocog.lrdc.pitt.edu (Jeff Shrager) writes:
p.s., Can anyone explain why the, um, I'm looking for a nice word to
describe the designers of C++, anyway.... why they didn't fix the
problem of having un-nestable comments, as the #|...|# in lisp will
nest. As a result of have unnestable commenting, you can't use
comments to comment out segments of code, which is among the most
powerful testing and revision tools. Do C programmers simply not
debug or something? I wouldn't be too surprised, actually. (For
those who have never tried to program in C/C++ (more power to you!),
if you go:
/* I don't want this piece of code to run...
some random code
that you don't want /* This line has an internal comment */
to run
*/
The middle */ closes the opening /* !!!
You can still do
#if 0
some random code
that you don't want /* This line has an internal comment */
to run
#endif
Yes! And the "some random code" could be (if strectched :) ) Common
Lisp. :) CPP is not necessarily a C only preprocessor :)
Cheers
--
Marco Antoniotti - Resistente Umano
===============================================================================
International Computer Science Institute | ·······@icsi.berkeley.edu
1947 Center STR, Suite 600 | tel. +1 (510) 643 9153
Berkeley, CA, 94704-1198, USA | +1 (510) 642 4274 x149
===============================================================================
...it is simplicity that is difficult to make.
...e` la semplicita` che e` difficile a farsi.
Bertholdt Brecht
From: Robert Munyer
Subject: Re: Parentheses readability
Date:
Message-ID: <4v4pnu$733@Mars.mcs.com>
In article <············@bart.nl>, Leo Sarasua <········@bart.nl> wrote:
> writing and reading a Lisp program is sometimes an undaunting
> task because of the parentheses. That's why I started long ago
> to use the following convention in my programs: when closing
> parentheses I leave a blank between those ')' parenthesis with
> a corresponding '(' in the same line and those whose corresponding
> '(' is in a different line above.
Years ago I tried something very similar to this. But I abandoned
it soon afterwards, because, like other Lisp programmers, I found
another approach that was simpler and (IMHO) better.
All you have to do is choose an indenting style and then use it
consistently. Once you have done this, you will soon find that
the only parentheses you ever look at are the left ones; the right
ones are "just there to make the indenting work."
Practicing consistent indenting is of course automatic if you use
an editor that's meant for Lisp. But with just a little practice
it's very easy to do, even with extremely primitive editing technology
(a chalkboard, for example).
-- Robert
From: ······@image.kodak.com (Michel Denber)
Newsgroups: comp.lang.lisp
Date: 19 Aug 1996 12:42:17 GMT
In article ···@bart.nl, Leo Sarasua <········@bart.nl> writes:
>I've been using this for quite a while now and it really helps. So my
>question is: Is anyone using a similar convention or is there any
>widespread method to improve lisp readability?
I just use SEdit, the structure editor that comes with Medley (formerly
Interlisp-D). When you type (, it automatically inserts a ). When you
point at an atom, it automatically selects the entire list that atom is
part of. I understand emacs does the same sort of thing. No one should
still have to count parentheses this late in the game.
Whaddayamean? I find myself visually balancing close parentheses in
Java all the time. Oh, you meant Lisp. Yeah, you're right.
:)