I have found myself caught in a "discussion" on
the ICAD User's Group mailing list (as most of you
probably know, ICAD/IDL language is a superset of
CL implemented on Allegro CL, used for knowledge-based
engineering mostly in automotive and aerospace
industries).
The person on the other end of the "discussion" is attempting
to defend the use of dangling parentheses, like this:
... )
)
)
)
instead of "stacked" (or "clumped" as he puts it), which I
am making a case is the defacto standard for formatting CL,
like this:
))))
The "discussion" has started going around in circles -- he gives his
many reasons ("things are easier to insert" "it is closer to other
languages like C and C++" etc.), but most of all his main claim
is that there is no "official standard" which says parens are to
be stacked like this in Lisp, so he will write his code as he
pleases, thank you very much.
Of course I am not too concerned with what this guy does personally,
but I am concerned about the impressions on the dozens or hundreds
of other ICAD/IDL users on the mailing list, many of whom are
rather naive and/or inexperienced about CL outside the context
of ICAD/IDL and might be easily misled.
I referenced the CL FAQ which does mention it ("Don't leave a paren
by itself on a line -- you will annoy programmers who grew up
in Lisp")
But despite copious examples (all published Lisp texts, etc.) the
FAQ is the only explicit reference I have come across, and apparently
this is insufficient for him.
The fact that virtually all published texts do not dangle parens he
dismisses as "well, that's for published books where the code is
printed in hardcopy and never has to be changed."
If necessary I do have permission to cross-post some of our "discussion"
here on c.l.l, but it would largely be noise for this audience. What would
be nice though, would be some explicit reference to a reasonably authoritative
statement about formatting conventions which supports the "stacked closing
parens" style.
Failing that, some good objective arguments as to why the stacked style
is preferable, both for readability and writability, would be welcomed.
Thanks,
Yours,
-dave
--
David J. Cooper Jr, Chief Engineer Genworks International
dco...@genworks.com 5777 West Maple, Suite 130
(248) 932-2512 (Genworks HQ/voicemail) West Bloomfield, MI 48322-2268
(248) 407-0633 (pager) http://www.genworks.com
[...]
> The person on the other end of the "discussion" is attempting
> to defend the use of dangling parentheses, like this:
>
> ... )
> )
> )
> )
>
[...]
"He who enters into a dispute with a fool can rest assured his
opponent has done the same."
-- ???
Don't won't waste your time on this guy if you can help it. As for his
insertion-speed argument: I'm guessing the Autolisp IDE doesn't have
the s-expression killing, transposing, rapid-navigation, etc.
facilities of Emacs. If you really want to spend your time on pinning
him down and nailing him, you could try getting specific and asking
for concrete examples of why <dangling-whatever> is faster, then put
the smack down and show him how it's done with Emacs.
Christopher
ICAD/IDL is not using the AutoLISP IDE. They use the Allegro CL IDE
(not emacs obviously)
The AutoLISP IDE has these above mentioned features: s-expression
killing, transposing, rapid-navigation, etc.
and three closing paren styles:
1) close at the same line (as in CL)
2) close at new line with inner indentation (as in emacs)
3) close at new line with outer indentation (as in typical autolisp
code as well as in david's sample)
coding conventions in various communities differ largely and this is NOT
based on the available tools. (though emacs require 'paren helps of
course)
emacs supports 1 and 2 and much more by customization,
VLISP supports just those 3 above, forgot about the ACL IDE now.
the more experience you have the briefer you get.
people without proper editors of course are doomed to use style 3 as
most of non-lisp folks also do. nothing against this style.
I also do it very often so that newbies can read it.
arguments:
brevity needs less scrolling. the more context you see in one page the
more you understand. the problems gets simplier to grasp.
indented closing parens as in algol-like languages are better readable
for the general non-lisp programmer and newbie.
horizontal structures seem to be less important than vertical blocks for
the unexperienced. hmm...
you can also insert and delete easier.
--
Reini Urban
http://xarch.tu-graz.ac.at/autocad/news/faq/autolisp.html
(with-shields-raised
Myself, I take the risk of being flamed by fundamentalist `stackers' on some
rare
occassions where I think dangling is the appropriate thing to do, eg:
) ; end of eval-when
) ; end of progn
wrapping top-level definitions
or cases like:
(declaim (special *foo*
...
*bar*
))
and even
(defstruct
slot1 ; comment 1
...
slotn ; comment n
)
on things that start getting prone to extension.
) ;)
--
Fernando D. Mato Mira
Real-Time SW Eng & Networking
Advanced Systems Engineering Division
CSEM
Jaquet-Droz 1 email: matomira AT acm DOT org
CH-2007 Neuchatel tel: +41 (32) 720-5157
Switzerland FAX: +41 (32) 720-5720
www.csem.ch www.vrai.com ligwww.epfl.ch/matomira.html
> The person on the other end of the "discussion" is attempting
> to defend the use of dangling parentheses, like this:
[...]
> The "discussion" has started going around in circles -- he gives his
> many reasons ("things are easier to insert" "it is closer to other
> languages like C and C++" etc.), but most of all his main claim
The fact that the dangling parentheses convention is closer to other
languages like C and C++ may be a good reason not to use it :)
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
you can't argue for _or_ against excessive whitespace on these grounds.
at issue is the relative importance of the delimiters. in C, the block
structure is very important and the visual clues in indentation are not
sufficiently perspicuous that they can be trusted for anything, so { and
} delimiters get extremely visually apparent formatting characteristics,
such as their own lines. in Common Lisp, the list structure is much less
important than the indentation, and the perspicuity of normal indentation
rules is sufficiently high that the parens are mainly used there for the
machine to use, not humans. therefore, humans would tend to get parens
in CL out of the (visual) way, while the braces in C must be very visible.
different languages have different optimization parameters for almost
every facet of their expression. trying to optimize CL code layout with
the parameters from C is completely braindamaged and merits nothing but a
snort, and people who are _that_ underdeveloped in their understanding of
the differences between languages should just be sedated and put away.
community standards grow out of such pragmatic optimization parameters,
and can't _actually_ be defended by reference to authority, because one
has to trust the authority to be representative of the community. one
must instead seek to understand how they got the way they are, and why
there may be minority and majority communities, as well. (a community of
one may be a brilliant loner or a nutcase, and it's hard to tell which is
which.) I think the need to understand how things came to be applies to
everything, but retracing the steps of decisions made by large groups of
people is usually quite depressing, so there is wisdom in accepting the
authorities at times. yet, accepting or rejecting authorities _because_
they are authorities is really retarded and people who are prone to this
should also be sedated and put away.
#:Erik
> Of course I am not too concerned with what this guy does personally,
> but I am concerned about the impressions on the dozens or hundreds
> of other ICAD/IDL users on the mailing list, many of whom are
> rather naive and/or inexperienced about CL outside the context
> of ICAD/IDL and might be easily misled.
Ask what style of C layout he uses. If he goes for things like
if (foo)
{
stuff
}
else
{
whatever
}
instead
of
if (foo) {
stuff
} else {
whatever
}
that should pretty much discredit him as a newbie loser in a C-oriented context
>:-I
Actually we do use Emacs, with customizations for indenting, colorizing,
etc. of ICAD/IDL (defpart) code. We use a (pretty nice) CLX-based thing
called "the ICAD Browser" for inspecting objects and drawing geometry,
etc.
In general we don't use the Allegro CL IDE.
You're right -- but saying nothing when someone is spewing potentially
misleading opinions has its disadvantages too (sometimes even at the risk
of seeming foolish). Anyway i think both sides agree that we've pretty
much milked this "discussion" dry, so unless there are any major revelations
it is time to move on anyway.
>
> Don't won't waste your time on this guy if you can help it. As for his
> insertion-speed argument: I'm guessing the Autolisp IDE doesn't have
> the s-expression killing, transposing, rapid-navigation, etc.
> facilities of Emacs.
>
Note that this is ICAD, not AutoCAD -- completely different kettle o' fish --
it's CL-based, nothing to do with Autolisp. Gnu Emacs is the default environment.
Thanks,
So even the AutoLISP IDE seems to not-discourage one-closing-paren-per-line.
So is it really such a bad thing to use this layout?
> arguments:
> brevity needs less scrolling. the more context you see in one page the
> more you understand. the problems gets simplier to grasp.
>
> indented closing parens as in algol-like languages are better readable
> for the general non-lisp programmer and newbie.
> horizontal structures seem to be less important than vertical blocks for
> the unexperienced. hmm...
> you can also insert and delete easier.
Nicely summarised!
The ICAD language we use uses some farily serious macros to turn our source
into real Lisp. THe stuff we write to define an object is basically a long
p-list of attribute/method/aggregate names and their definitions. Since
each definition rearly takes more than half a screenful, the problem with
scrolling vertically doesn't really occur. The ability to insert and delete
easier saves me a great deal of time.
I am not a newbie to ICAD, as I have been writing code in ICAD full time for
the last eight years.
Cheers!
Anthony
------------------
Anthony Cartmell
Application Architect
New Design Paradigm
Worthing, England
Tel. +44 1903 201084
E-mail: AJCar...@csi.com
I use the first layout form, which happens to have been adopted as the
recommended layout for Symbian's EPOC C++ coding (the operating system
that's about to take over the world!). I'm not sure why my C++ layout has
anything to do with Lisp layout though?
I'm actually an experienced ICAD/Lisp programmer (eight years, successful
applications released to multiple clients) and a newbie in C++.
I'm still waiting for a reason why Lisp people are so against
paren-per-line...
Seems to me that this really is the main reason... is the Lisp layout
"standard" really this sad?
Sorry for the "newbie" question, but I thought that the indentation was
based on the list structure, and not the other way round. If the parens
were based on the indentation then we wouldn't even need to use them. My
whole reason for using dangling parens in my code is to show which
open-paren each close-paren closes by its indentation. I don't understand
why this is such a bad layout style.
> different languages have different optimization parameters for almost
> every facet of their expression. trying to optimize CL code layout with
> the parameters from C is completely braindamaged and merits nothing but
a
> snort, and people who are _that_ underdeveloped in their understanding
of
> the differences between languages should just be sedated and put away.
I lay my Lisp code out the way I do for the reason given above, and not
because of any other language's layout style.
> which.) I think the need to understand how things came to be applies to
> everything, but retracing the steps of decisions made by large groups of
> people is usually quite depressing, so there is wisdom in accepting the
> authorities at times. yet, accepting or rejecting authorities _because_
> they are authorities is really retarded and people who are prone to this
> should also be sedated and put away.
Couldn't agree more. What I'm trying to do, prompted by criticism of my
code layout in a public place, is to find out *why* the Lisp community
rejects one-paren-per-line apparently so strongly. If there's a good reason
I *may* change the coding layout I've used successfully, with others, for
the last eight years.
Does anyone know?
> "He who enters into a dispute with a fool can rest assured his
> opponent has done the same."
This isn't a dispute, and neither of us are fools. I've used my layout
style efficiently for the last eight years, having abandoned
put-all-close-parens-on-the-same line for reasons of readability and editing
speed. David pointed out that "real Lisp programmers"(TM) frown on this
style, and I'm trying to find out why.
> Don't won't waste your time on this guy if you can help it. As for his
> insertion-speed argument: I'm guessing the Autolisp IDE doesn't have
> the s-expression killing, transposing, rapid-navigation, etc.
> facilities of Emacs. If you really want to spend your time on pinning
> him down and nailing him, you could try getting specific and asking
> for concrete examples of why <dangling-whatever> is faster, then put
> the smack down and show him how it's done with Emacs.
I use Emacs, which as you know, has various keystrokes for cutting out
complete forms, so clumped parens are relatively easily dealt with.
Since I also find myself using vi, I find that whole-line edits are easier
than relying on Emacs tools.
Concrete example of how dangling parens makes my coding more efficient:
Insert (list 1) at the end of the form starting (list 0 ...) in the
following:
(list a
(list b c d)
(list 0
(list e f g
(list h))))
Without careful paren-counting or an editor that will match for you, it's
tricky and error prone. It also seems tricky to me to check that the (list
a ...) has the correct number of close parens without relying on editor
features to indicate this.
(list a
(list b c d)
(list 0
(list e f g
(list g)
)
)
)
With this layout I can see instantly where to insert the new form. The
insert is easy as in all editors as I only have to add a new line with the
form in it. No editing of the existing code lines is required at all! I
can also see straight away that the (list a...) form has balanced parens.
I would have thought that a layout style that depends on a particular type
of editor being available would be frowned upon in purist circles?
> I'm still waiting for a reason why Lisp people are so against
> paren-per-line...
Short answer: Please reread the posting in this thread by Erik Naggum.
Long answer: There is no `reason' as such. However, if you go into a chip shop
in Whitby and order cod and chips twice in a very broad somerset burr, you may
not get what you ordered. However, if you were to order using recieved
pronunciation or in a local accent/dialect you are much more likely to be
understood.
This is the same with paren-per-line, there is an accepted way of
communicating and this is not paren-per-line. If you do want to be understood
by the majority of lisp programmers please follow your suggested layout.
Best Regards,
:) will
See my response to his post - I don't see any reasons for avoiding
one-paren-per-line in his post. All he says is that we should try to find
out *why* is has become accepted to avoid one-paren-per-line. That's what
I'm trying to do!
> Long answer: There is no `reason' as such. However, if you go into a chip
shop
> in Whitby and order cod and chips twice in a very broad somerset burr, you
may
> not get what you ordered. However, if you were to order using recieved
> pronunciation or in a local accent/dialect you are much more likely to be
> understood.
Wow, so "real Lisp programmers"(TM) might think that:
(list a b
(list c d)
(list e)
)
)
means something different to
(list a b
(list c d)
(list e)))
might they? I can't see where any confusion as to the meaning of the Lisp
can come in here. All I can see is a different layout, which some may find
less pleasing to their eyes - is this really a good enough reason to abandon
what I find an efficient layout for editing Lisp?
Thanks for your input!
> See my response to his post - I don't see any reasons for avoiding
> one-paren-per-line in his post. All he says is that we should try to find
> out *why* is has become accepted to avoid one-paren-per-line. That's what
> I'm trying to do!
Read it again.
The point is that (ironically?) parsing parantheses is not what you
do when you read well-written well-indented lisp code, you can (almost)
ignore the parantheses and concentrate on the semantics.
Reading lisp code written the weay you do is less efficient because the
single parantheses draw unneccesary attention and use up valuable lines.
--
(espen)
> Wow, so "real Lisp programmers"(TM) might think that:
>
> (list a b
> (list c d)
> (list e)
> )
> )
>
> means something different to
>
> (list a b
> (list c d)
> (list e)))
>
> might they?
Yes. However, I am not a real Lisp programmer.
> I can't see where any confusion as to the meaning of the Lisp
> can come in here.
That is clear. But your inability to understand the confusion is not my problem.
> All I can see is a different layout, which some may find less pleasing to
> their eyes - is this really a good enough reason to abandon what I find an
> efficient layout for editing Lisp?
Well, that depends whether you want anybody else to understand your code. If you
are an evil genius who wants to take over the world through the use of
misfomatted (or is that `formattingly challenged' code) please continue. But
respect the rights of other to point out that there is a defacto standard and
your way is not it.
Cheers,
:| will
> > Long answer: There is no `reason' as such. However, if you go into
> > a chip shop in Whitby and order cod and chips twice in a very
> > broad somerset burr, you may not get what you ordered. However, if
> > you were to order using recieved pronunciation or in a local
> > accent/dialect you are much more likely to be understood.
>
> Wow, so "real Lisp programmers"(TM) might think that:
>
> (list a b
> (list c d)
> (list e)
> )
> )
>
> means something different to
>
> (list a b
> (list c d)
> (list e)))
>
> might they?
No, but it might well take them longer to
digest; if you are used to
seeing lisp code in one particular layout and are
confronted with pages and pages of code laid out in a different
manner, it grates. Like when someone
posts with lines ~100 characters long on USENET, for
example.
I think this was the point Will was trying to make.
> I can't see where any confusion as to the meaning of the Lisp can
> come in here. All I can see is a different layout, which some may
> find less pleasing to their eyes - is this really a good enough
> reason to abandon what I find an efficient layout for editing Lisp?
Your call; but if you want to communicate with the wider lisp
community it would be easier if you chose the accepted layout.
Cheers,
M.
--
well, take it from an old hand: the only reason it would be easier
to program in C is that you can't easily express complex problems
in C, so you don't. -- Erik Naggum, comp.lang.lisp
> Without careful paren-counting or an editor that will match for you, it's
> tricky and error prone. It also seems tricky to me to check that the (list
> a ...) has the correct number of close parens without relying on editor
> features to indicate this.
But the `without an editor that will match for you' is a silly
question. it's hard to work out where the close parens should go if
you edit an octal dump, too.
> I would have thought that a layout style that depends on a particular type
> of editor being available would be frowned upon in purist circles?
Common Lisp is not a purist language, thank God. We like to assumer
people have a reasonably competent editor, especially since such
editors have been freely available for more than half the lifetime of
Lisp.
--tim
The point is that parens are there *for the computer* not for the
human reader. For the human reader they are almost purely visual
noise, which should be minimised -- understanding programs is hard
enough without extra visual clutter. Putting one close paren per line
gives you no useful information (you don't care about where a unit of
the program ends, only where the next one starts, after all), causes
maximum visual noise, and takes up valuable whitespace on the page to
boot.
The only reason for using paren per line is if you have an editor
which is purely line-based. The traditional lisp-person's response to
being in this situation is to write one that isn't.
--tim
> Sorry for the "newbie" question, but I thought that the indentation was
> based on the list structure, and not the other way round. If the parens
> were based on the indentation then we wouldn't even need to use them. My
This is somewhat analogous to putting punctuation marks on their own
lines in english language: Since the grammatical structure of a
sentence will already point out fairly well, where each sentence or
phrase ends, there isn't much point in exagerating the importance of
punctuation marks beyond all reasonable proportions. Punctuation is
important, since it disambiguates and modifies sentence meanings and
length in a number of cases. But it isn't the sole or even most
important means of recognizing sentence length, structure and
meaning. So Don't elide punctuation, but don't exagerate it's
importance either.
Parens help the compiler to disambiguate, whereas indentation helps the
programmer to disambiguate. Since computers aren't very adept at
spatial vision/recognition, and humans not very good at keeping track
of state[1], it seems to me a good decission to have two seperate ways
of disambiguation, with tool support for keeping the two in sync.
With that in mind, it seems clear that parens should follow
indentation (though not necessarily in the direct form that you
probably had in mind, i.e. by identation being syntactically relevant)
and not vice versa, since (usually) humans write code, and not
computers. Furthermore, since humans are very accustomed to
interactive work, the way that parens follow indentation is by
commands for reindenting code based on paren structure. You might
want to visit Deja.com and search for an article by Erik Naggum dated
09 Jun 1999 with a subject of: "Re: Lisp syntax, what about
resynchronization?" (Message-ID: <31379290...@naggum.no>). Here
is a small excerpt:
(quote
| Inspecting the indentation does not neccessarily reveal errors.
I didn't say "inspect", Tom. what I said was, _when_ you are editing,
and you are inserting and deleting parenthesis, you will naturally have
expectations as to what the indentation will be. that is, if we're still
assuming that programmers are humans. you give me the impression that
you argue in a world where they are not, which rhymes well with my own
great vision of the future, where computers program people, but this is
still some ways off, and until then, we have to deal with people typing
and seeing what they do. so instead of your silly interpretation of
inspecting the indentation, I _actually_ said we should watch the
_changes_ that Emacs makes to the indentation when we reindent code that
has been changed. you have obviously never done this, so let me explain
what it means: suppose you add a binding to a LET form, but you forget to
close the outermost parenthesis in what you added. reindent. watch how
completely unrelated lines suddenly move. this is such a fantastically
simple task most people have to be shown it to understand that it is NOT
a question of inspecting a _static_ indentation, but of watching Emacs
make _unexpected_ changes to indentation. the rule of thumb is: if
something you don't expect to move, moves, you've made a mistake, and
undo the indentation immediately, and go fix it.
)
> whole reason for using dangling parens in my code is to show which
> open-paren each close-paren closes by its indentation. I don't understand
> why this is such a bad layout style.
Because there are much better tools for matching parens than writing them
on an extra line, namely editors. Any reasonable editor will have support
for blinking/flashing/highlighting matching parens and/or the text they
surround. They will have commands to close all open parentheses, to move
around the code s-exp wise, to transmogrify s-exps, etc. Given this
amount of tool support, it seems more than unwise not to use it.
Try to reformat the above posting with dangling punctuation marks, and
see how difficult it becomes to read.
Regs, Pierre.
Footnotes:
[1] You need a stack to balance/check parens, and the human stack
maybe as short as 5-10 elements, with 7 often quoted as the
average.
--
Pierre Mai <pm...@acm.org> PGP and GPG keys at your nearest Keyserver
"One smaller motivation which, in part, stems from altruism is Microsoft-
bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
> I would have thought that a layout style that depends on a particular type
> of editor being available would be frowned upon in purist circles?
But Common Lisp is not about puritanism! It is about putting as much of
the human experience and computing power to bear on a problem as is
possible. If we wanted to be puritanical, we'd still be toggling
panels. Or frowning about vi, since it's one of those newfangled
visual editors (which came into common use only fairly recently,
namely the 70s). Live's to short to be puritanical. There's a thin
line between being puritanical and letting everyone dump their garbage
into your house, and Common Lisp is trying to follow this line, and
has been doing so in one form or another (including it's venerable
predecessors) for the last 40 years. That's why I use Common Lisp,
and don't cling to the past, or overpromise on the future.
Regs, Pierre.
> > Ask what style of C layout he uses. If he goes for things like
> >
> > if (foo)
> > {
> > stuff
> > }
> > else
> > {
> > whatever
> > }
> I use the first layout form, which happens to have been adopted as the
> recommended layout for Symbian's EPOC C++ coding (the operating system
> that's about to take over the world!). I'm not sure why my C++ layout has
> anything to do with Lisp layout though?
<rant>
The above format is typically (but not exclusively) found in source code
written
by "EE C hackers", meaning people who studied how to design hardware,
but who dare to write software professionaly when their knowledge of
"software engineering" limits itself mainly to hacking C(++) and assembler.
There's a common attitude among a lot of EEs regarding "software is easy" and
"I obviously can do that too".
Of course there always exist the case of an EE becoming a true SE, but as
generalities
go, is not the worst one.
Note that that doesn't mean the ones writing it are newbies or that they
really suck.
As a matter of fact, that style is found in a library from a major hadware
company
which would be highly nontrivial to reimplement. But there you have it:
"hardware".
<rant>
Maybe if it were more design-oriented and not so much fast-iron-oriented they
would also not be so C(++)-centric, and they would be in a better shape by
not being
so much affected by commoditization.
</rant>
</rant>
Obviously, this doesn't mean it doesn't exist beautiful [what an oxymoron
;->]
code written in the first form, and lots of trash [no wittiness here either,
please ;->] using the second one.
Look at the Linux kernel sources. It uses almost exclusively the second
style.
If Linus and Alan cannot be taken as prototypes of the modern real C
programmer,
I don't know who could.
What would this have to do with Lisp?
If you believe someone has bad taste in domain A it
supports the hypothesis that the might also have bad taste in the less
familiar domain B.
Would I write Eiffel like this?
if foo begin
end
I don't think so.
Should a FORTRAN programmer leave 7 spaces to the left when writing C, or
more to the point, WRITE LIKE THIS, when modern FORTRAN is written like this?
You think Pascal and C programmers write_like_this because they cannot write
like this,
or more probably, because they cannot write-like-this?
A good question is:
if we write
(if cucu
(progn
waka
(if foo
(progn
bar
baz))))
shouldn't we also write like this:
if (cucu) {
waka;
if (foo) {
bar;
baz;}}
Something seems WRONG, doesn't it?
Probably the semicolon is at fault. Let's try again:
if (cucu) {
waka;
if (foo) {
bar;
baz}}
Now it looks bad because there's no semicolon!
One more time:
if (cucu) {
waka;
if (foo) {
bar;
baz;
}}
Is this right? Let's see:
if (cucu) {
waka;
if (foo) {
bar;
baz;
}}
else {
rythm
blues
}
Hmm.. Let's do it again:
if (cucu) {
waka;
if (foo) {
bar;
baz;
}}
else {
rythm
blues
}
NO WAY!!
if (cucu) {
waka;
if (foo) {
bar;
baz;
}
}
else {
rythm
blues
}
What was that thing I wrote at the beginning again?
> Wow, so "real Lisp programmers"(TM) might think that:
>
> (list a b
> (list c d)
> (list e)
> )
> )
>
> means something different to
>
> (list a b
> (list c d)
> (list e)))
>
> might they? I can't see where any confusion as to the meaning of the Lisp
> can come in here. All I can see is a different layout, which some may find
> less pleasing to their eyes - is this really a good enough reason to abandon
> what I find an efficient layout for editing Lisp?
I'm a `real Lisp programmer'(TM) (at least that's what I'm paid for),
and although it is obvious to me that the first form and the second
form evaluate to the same thing, if I were to come across the first
form in a program that were otherwise normally indented, I'd assume
that `something odd' is going on, and that the programmer choose a
funny indentation to draw attention to the fact that some assumptions
are being violated.
So, yes, I probably would think that the *intent of the programmer*
would be very different if he deliberately chose the first indentation
over the second.
The point of indentation and code layout (for a language where
whitespace is *not* significant), is to make the intent of the code
clearer to the reader. The `standard' indentation is the convention,
so it should be followed unless a `non-standard' indentation is called
for.
But can we get back to more important subjects, like whether Lisp is
better than C, whether Scheme is a dialect of Lisp, where the free
Lisp compilers are, and how to do simple homework exercises without
really trying?
--
~jrm
I have done. The meaning hasn't changed (and I still don't think he can
separate the list structure from the indentation - they are rigidly linked).
He still says:
> yet, accepting or rejecting authorities _because_
> they are authorities is really retarded and people who are prone to this
> should also be sedated and put away
I am questioning the authority decision that said that dangling parens are
not to be used in Lisp code. I'm not really interested in the fact that you
can read and write code without dangling parens, I'm just interested in why
that layout style is frowned upon. It seems that people avoid dangling
parens just because someone said so, and for no logical reason to do with
coding in Lisp.
> The point is that (ironically?) parsing parantheses is not what you
> do when you read well-written well-indented lisp code, you can (almost)
> ignore the parantheses and concentrate on the semantics.
The clue is in the (almost) - although I'd agree that reading Lisp code
formatted with nice indentation and stacked closing parens is probably as
easy as with dangling parens, it's easier to *edit* code that has dangling
parens, because when *editing* the parentheses *cannot* be ignored.
> Reading lisp code written the weay you do is less efficient because the
> single parantheses draw unneccesary attention and use up valuable lines.
I disagree. I find the single parentheses have a useful purpose to indicate
the indentation levels of the code they close. This make editing much
easier. I use a large modern computer screen and so lines are no longer as
valuable as when we used to use small text-only terminals. In fact I find
the white space introduced by dangling parens is positively useful when
reading large blocks of code.
Perhaps we disagree on layout because pure Lisp is based on many small
function definitions with deep nesting, whereas ICAD code is based on a
plist structure with shallow nesting.
Oh dear, my opinion of "real Lisp programmers"(TM) has been somewhat dented
if they can't understand that whitespace (including newlines) doesn't change
the meaning of the code.
> > I can't see where any confusion as to the meaning of the Lisp
> > can come in here.
>
> That is clear. But your inability to understand the confusion is not my
problem.
Errr... no, I didn't say it was. I was asking someone to explain where the
confusion occurs - I'd like someone to enlighten me! Please!
> > All I can see is a different layout, which some may find less pleasing
to
> > their eyes - is this really a good enough reason to abandon what I find
an
> > efficient layout for editing Lisp?
>
> Well, that depends whether you want anybody else to understand your code.
Why on earth should they *not* understand my code? I've seen postings from
other people on this newsgroup which have been answered perfectly well even
though the original poster used dangling parens. No misunderstandings
there.
> If you
> are an evil genius who wants to take over the world through the use of
> misfomatted (or is that `formattingly challenged' code) please continue.
But
> respect the rights of other to point out that there is a defacto standard
and
> your way is not it.
I'm very intrigued by this defacto standard that everyone seems is *so*
important to defend, but which does not seem to be defendable by any other
argument than "this is the way we have always done it, so it must be right
and all other ways are wrong".
I'm not trying to change the way anyone else lays out their code, I'm trying
to find out whether I should make the effort to change. So far I'm not
convinced that there's any benefit.
Cheers!
> It seems that people avoid dangling
> parens just because someone said so, and for no logical reason to do with
> coding in Lisp.
I think you're wrong. I think it's NOT an authority decision, but the
*best* decision because it maximises ease of readability of the
experienced lisp code reader.
> The clue is in the (almost) - although I'd agree that reading Lisp code
> formatted with nice indentation and stacked closing parens is probably as
> easy as with dangling parens, it's easier to *edit* code that has dangling
> parens, because when *editing* the parentheses *cannot* be ignored.
I disagree. Editing code without the dangling parens is just as easy
(provided you use a sensible editor, of course).
--
(espen)
No it's not, I'm editing text here, and sometimes I don't have Emacs handy
at a client site. It seems perfectly reasonable to lay out my source *text*
so that a *text* editor can be used to easily edit it.
Anyway the fact that we ususally have a clever text editor like Emacs
doesn't mean that we *have* to clump parens together, it just means that we
*can* if we want to. It can't be the reason that dangling parens are
frowned upon.
Anthony
So why should I cling to the past and remove all my dangling parens? It's
not a major style change - I'm not even changing indentation rules! Why is
this such a big issue for other Lisp programmers?
Anthony
------------------
> Oh dear, my opinion of "real Lisp programmers"(TM) has been somewhat dented
> if they can't understand that whitespace (including newlines) doesn't change
> the meaning of the code.
Lisp programmers are interested in understanding the *intent* of the
person who wrote the code. That intent is indicated by things like
formatting, comments, choice of names and so on. If the formatting is
weird, they will assume the intent is too.
--tim
>
> I disagree. Editing code without the dangling parens is just as easy
> (provided you use a sensible editor, of course).
If you don't have an editor that does automatic indentation but that
highlights matching parentheses, it's easier to stack. You don't
have to manually move all dangling parentheses when you wrap
existing code in a control structure:
eg:
(progn
foo
(if waka
mole
)
)
(if cucu
(progn
foo
(if waka
mole
)
)
)
(progn
foo
(if waka
mole))
(if cucu
(progn
foo
(if waka
mole)))
If you can't expr-indent but only region-indent, less motion is required to
mark the region, too.
If you can expr-indent, you move less to unwrap control structure. You just
delete parens at the end.
> > That is clear. But your inability to understand the confusion is not my
> problem.
>
> Errr... no, I didn't say it was. I was asking someone to explain where the
> confusion occurs - I'd like someone to enlighten me!
Although you claim you would like somebody to enlighten you, I am not sure that
I can.
> I'm not trying to change the way anyone else lays out their code, I'm trying
> to find out whether I should make the effort to change. So far I'm not
> convinced that there's any benefit.
I would suggest that it is well worth changing if only to stop having these
rather tedious exchanges. A number of people, many of whom are far more expert
than me, have given what I believe to be convincing explanations. And yet you
persist. Could anybody convince you to change your mind?
A while ago an acquaintance of my told me I should chill and be more Zen. As I
found what I see as your attitute irksome (which is my problem, since I'm sure
this is because I'm projecting my nasty cynical attititudes onto your virtuous
quest for parenthesis enlightenment) until I remembered this advice and thought
of the following story:
`Provided he makes and wins an argument with those who live there, any wandering
monk can rest in a temple while if he is defeated, he must move on.
In a temple in the northern Japan lived two brother monks: one was learned, the
younger stupid with but one eye.
A wandering monk came and asked for lodging, properly challenging them to a
debate. The elder brother, tired from much studying, told the younger one to
take his place. Request the dialogue in silence, he cautioned.
The young monk went with the stranger to the shrine and sat down. Shortly
afterwards the traveler rose and went in to the elder brother and said: "Your
young brother is a wonderful, he defeated me."
"Relate the dialogue to me", said the elder monk. "Well," explained the
traveler, "first I held up one finger, representing the enlightened one. So he
held up two fingers, signifying Buddha and his teaching. I held up three
fingers, representing Buddha, his teaching, and his followers. Then he shook his
clenched fist in my face, indicating that all come from one realization. He won
and I have no right to remain." With this he left.
Running in to his elder brother, the young monk asked "Where is that fellow?" "I
understand you won," said the elder brother. "Won nothing. I'm going to beat him
up."
"First tell me the subject of the debate." "Why, the minute he saw me he held up
one finger, insulting myone eye. Since he was a stranger I held up two fingers,
congratulating him that he has two eyes. Then the wretch held up three fingers,
suggesting that between us we only have three eyes. I got mad and started to
punch him, but he ran out and that ended it!"'
Cheers,
:) will
Agreed for human-readable english text. Punctuation is of secondary
importance to the words in order to understand meaning - the actual sentence
structure is of little interest. But in Lisp the "sentence structure" is
crucial to the meaning - the order of items and their nesting level are of
the utmost importance.
> surround. They will have commands to close all open parentheses, to move
> around the code s-exp wise, to transmogrify s-exps, etc. Given this
> amount of tool support, it seems more than unwise not to use it.
But just because I happen to use a fancy text editor most of the time, why
do I *have* to use its features in preference to simpler features that *any*
text editor can handle. Especially when these features are, in my personal
opinion are irrelevant to my coding style?
> Try to reformat the above posting with dangling punctuation marks, and
> see how difficult it becomes to read.
Had it contained may nested parens it would have been a little easier to
read, and much easier to comment/edit, in my opinion. But since it was
effectively a flat list of words, nope. Lisp is not english.
> [1] You need a stack to balance/check parens, and the human stack
> maybe as short as 5-10 elements, with 7 often quoted as the
> average.
Unless.... wait for it... you use *indentation* to show which close parens
go with which open parens!!
Thanks for some interesting thoughts,
I find that putting one paren per line gives me much useful information,
based on its indentation position. With nested forms I *do* care where one
level of nesting *ends*, so that I can insert additional forms at a higher
level in the nest. Perhaps this doesn't happen often in pure Lisp, but it
sure does happen a lot in ICAD. For me the benefit this gives me far
outweighs any minor "visual noise" or "lines-per-page" issues.
> The only reason for using paren per line is if you have an editor
> which is purely line-based. The traditional lisp-person's response to
> being in this situation is to write one that isn't.
I'm looking for reasons for *not* using one paren per line. So far I have:
1) Lisp people just don't do it, for reasons lost in the mists of time,
probably to do with small screens.
2) It doesn't look nice for people who are not used to looking at that
layout style - "visual clutter".
3) Errr...
4) that's it.
Can anyone extend my list?
Phew! Can you tell me what's wrong with this layout style for C++? Perhaps
we should be warned!
> Obviously, this doesn't mean it doesn't exist beautiful [what an oxymoron
> ;->]
> code written in the first form, and lots of trash [no wittiness here
either,
> please ;->] using the second one.
My point exactly.
> What would this have to do with Lisp?
Absolutely nothing!
You have not said anything about the *kind* of Lisp programming you do.
From what I remember of ICAD, I suspect that your problem domain is
already compartmentalized and restricted, and that you modify code, or
construct new functions/structures in a somehow predefined way? If this
is the case, I could understand why you wish to present code the way you
advocate. It is, as you say, easier to single out particular
expressions, although only if you are familiar with it already.
But Lisp programming is not generally like that. I seldom "read" Lisp
code nowadays, yet I find it difficult to grasp code that is presented
your way. The structure of the code becomes blurred.
> Errr... no, I didn't say it was. I was asking someone to explain where the
> confusion occurs - I'd like someone to enlighten me! Please!
There is no confusion. What you have now are responses from people who
are used to dealing with large pieces of Lisp code at once. Your way
makes that task more difficult, that's all.
> I'm very intrigued by this defacto standard that everyone seems is *so*
> important to defend, but which does not seem to be defendable by any other
> argument than "this is the way we have always done it, so it must be right
> and all other ways are wrong".
All we are saying is that your way is not well suited for understanding
Lisp code. And the argument is not "this is the way we have always done
it", but "this is the way we have found to be most convenient". Do you
not want to accept that?
> I'm not trying to change the way anyone else lays out their code, I'm trying
> to find out whether I should make the effort to change. So far I'm not
> convinced that there's any benefit.
You could perhaps ask your (ICAD) Lisp code readers? Surely they are the
people that should have first say on this topic.
Regards,
Lars
> I'm very intrigued by this defacto standard that everyone seems is *so*
> important to defend, but which does not seem to be defendable by any other
> argument than "this is the way we have always done it, so it must be right
> and all other ways are wrong".
I wonder what side of the road you drive on?
nope.
I was as taken aback by your coding style as most on this list. It just
doesn't look like good Lisp. Realistically, though, there aren't any
"good" reasons not to do it your way. I don't. Why? Well, it looks
bad to me. Also, I like to see more of my code. This isn't because I
have a small screen, it's just a personal preference. I like my Lisp
compact and visible. Finally, I find that dangling parens are
distracting (the visual noise issue). Do I care if you format your Lisp
the way I format mine? Sure, if I have to read it. Do I care if you
format your ICAD code the way I do? Nope, because I'll never see it.
In short, your formatting drives me up the wall, but it's a personal
preference. Do what makes you the most productive. But if you ever
send me your code, please take out the dangling parens. If you ask
nice, I'll put them back in before I return it.
Enjoy!
Thom
Thom Goodsell
Scientist t...@cra.com
Charles River Analytics (617) 491-3474 x574
Cambridge, MA, USA http://www.cra.com/
I drive on the left, to avoid bumping into traffic coming the other way. In
the USA people drive on the right for the same reason. Which method is
wrong?
I guess the difference is indeed that ICAD is not Lisp. I think we must use
long lists and plists much more than Lisp programmers who seem to use nested
lists much more. So our requirements when editing code are different.
Presumably in pure lisp programming its more rare to need to insert stuff in
between stacked closing parens, and obviously in that situation stacking
them is the best thing to do.
> There is no confusion. What you have now are responses from people who
> are used to dealing with large pieces of Lisp code at once. Your way
> makes that task more difficult, that's all.
Yup, again, ICAD is different to Lisp, and seems to require different code
layout.
> You could perhaps ask your (ICAD) Lisp code readers? Surely they are the
> people that should have first say on this topic.
That's where we started, but someone thought that sticking to the Lisp
convention was a good idea, and I decided to see what benefits that might
bring.
Thanks for your useful comments.
The best reason I've ever heard is that for an experienced Lisp
programmer, parentheses *disappear* . You no longer notice them (I
call this state `lisp enlightenment' myself) [1]. As one poster
mentioned, parentheses are like punctuation marks which fade into the
background.
So putting each parenthesis on a line by itself causes the parens to
reappear. People who are used to not seeing them get annoyed and
often move them to the `right place' anyway before trying to read the
code. They do the same thing with stuff like the following:
( defun foo ( bar baz )
( cond ( ( list bar )
( append bar baz ) )
( t
nil ) ) )
which hurts even to look at and makes me feel like visiting the eye
doctor to get my prescription updated.
But apart from being merely annoying, one of the things most lisp
programmers want is to see everything at once. In the lisp-machine
days, people used to use small fonts and extremely long lines so they
could compress a function or even a group of functions to a single
visual unit or page. Putting a single paren on a line by itself
defeats this desire.
Other programming languages, like C, depend on whitespace to make the
code readable. The plethora of punctuation --- brackets, braces,
periods, arrows, asterisks, etc. place excessive demands on human
visual processing capabilities. I say this as a recovering C
programmer. :-) I can't even LOOK at Java without getting queasy. But
even when programming in C I used to do my best to avoid pushing code
out of sight.
[1] While composing this message I put the preceeding parenthetic
phrase in the wrong place. I was able to use C-M-k to grab it and
move it to the right place. That's how the right editor can make it
easy to deal with lisp expressions as units.
--
Fred Gilham gil...@csl.sri.com
I have over the years been viewed as a man of the left and a man of
the right, and the truth is that I've never put much stake in such
labels. But this I have learned: the left patrols its borders and
checks membership credentials ever so much more scrupulously, even
ruthlessly, than does the right. -- Richard John Neuhaus
> I find that putting one paren per line gives me much useful information,
> based on its indentation position. With nested forms I *do* care where one
> level of nesting *ends*, so that I can insert additional forms at a higher
> level in the nest. Perhaps this doesn't happen often in pure Lisp, but it
> sure does happen a lot in ICAD. For me the benefit this gives me far
> outweighs any minor "visual noise" or "lines-per-page" issues.
Sure it happens a lot in Lisp. BUT we do it with lisp-syntax-aware editors.
If, as you claim, you're restricted to not using one, then perhaps
your style is reasonable. I pity you if so.
The point is that when you read code you read *the code* not the
parens:
defun x (y)
if evenp y
+ y 1
y
Unfortunately the lisp system needs some extra information to parse
this, but the idea is to make this extra information as invisible as
you possibly can, not to revel in it.
I'm going to give up now as I don't think you're interested in being
persuaded.
--tim
PS if you followup to this *don't* send a mail copy, it's rude (just a
stupid convention, I know).
> Phew! Can you tell me what's wrong with this layout style for C++? Perhaps
> we should be warned!
I guess it's mostly about wasted screen real-state, which is at a premium.
Wasting lines
in { and }, and the double amount of characters per indentation level sucks
(and I wouldn't
like to have to type them in a brain-damaged editor, either).
If someone thinks "loser" for subtilities like that, what is he going to think
when he has to see
half the screen going:
)
)
)
)
)
)
)
)
)
)
)
)
)
)
That the one writing that code does not really know lisp, and he'd better throw
it away, that's what.