Dangling Closing Parentheses vs. Stacked Closing Parentheses
David J. Cooper
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
Andrew K. Wolven
corrected with immediate and overwhelming force.
Christopher R. Barry
[...]
> 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
Reini Urban
>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.
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
Fernando D. Mato Mira
to find a case where you can agree with your opponent.
(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
Paolo Amoroso
wrote:
> 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/
Erik Naggum
| The "discussion" has started going around in circles -- he gives his many
| reasons ("things are easier to insert" "it is closer to other languages
| "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.
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
Fernando D. Mato Mira
> 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
David J. Cooper
>
> ICAD/IDL is not using the AutoLISP IDE. They use the Allegro CL IDE
> (not emacs obviously)
>
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.
David J. Cooper
>
> "He who enters into a dispute with a fool can rest assured his
> opponent has done the same."
>
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,
Anthony Cartmell
> 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)
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
Anthony Cartmell
>
> 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
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...
Anthony Cartmell
> languages like C and C++ may be a good reason not to use it :)
Seems to me that this really is the main reason... is the Lisp layout
"standard" really this sad?
Anthony Cartmell
"Erik Naggum" <er...@naggum.no> wrote in message
news:31630313...@naggum.no...
> 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.
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?
Anthony Cartmell
in
the discussion.
> "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?
William Deakin
> 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
Anthony Cartmell
"William Deakin" <wi...@pindar.com> wrote in message
news:38DF41EB...@pindar.com...
> Anthony Cartmell wrote:
>
> > 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.
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!
Espen Vestre
> 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)
William Deakin
> 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
Michael Hudson
> > 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
Tim Bradshaw
> 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
Tim Bradshaw
> 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!
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
Pierre R. Mai
> 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]
Pierre R. Mai
> 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.
Fernando D. Mato Mira
> > 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?
Joe Marshall
> 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
Anthony Cartmell
"Espen Vestre" <espen@*do-not-spam-me*.vestre.net> wrote in message
news:w6hfdsl...@wallace.nextel.no...
> "Anthony Cartmell" <AJCar...@csi.com> writes:
>
> > 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!
>
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.
Anthony Cartmell
> Anthony Cartmell wrote:
>
> > 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?
>
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!
Espen Vestre
> 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)
Anthony Cartmell
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.
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
Anthony Cartmell
"Pierre R. Mai" <pm...@acm.org> wrote in message
news:87r9cwz...@orion.dent.isdn.cs.tu-berlin.de...
> 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
> 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.
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
------------------
Tim Bradshaw
> 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
Fernando D. Mato Mira
>
> 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.
William Deakin
> > 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
Anthony Cartmell
> "Anthony Cartmell" <AJCar...@csi.com> writes:
>
> > 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.
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,
Anthony Cartmell
"Tim Bradshaw" <t...@cley.com> wrote in message
news:ey34s9s...@cley.com...
> 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.
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?
Anthony Cartmell
"Fernando D. Mato Mira" <mato...@iname.com> wrote in message
news:38DF6134...@iname.com...
> <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
> 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>
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!
Lars Lundback
>
>
> 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.
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
Joe Marshall
> 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?
Thom Goodsell
> <snip, snip, snip>
> 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?
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/
Anthony Cartmell
"Joe Marshall" <jmar...@alum.mit.edu> wrote in message
news:un1nkm...@alum.mit.edu...
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?
Anthony Cartmell
news:38DF8C7F...@era.ericsson.se...
> 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.
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.
Fred Gilham
"Anthony Cartmell" <AJCar...@csi.com> writes:
>
> 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!
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
Tim Bradshaw
> 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).
Fernando D. Mato Mira
> 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.
Fernando D. Mato Mira
> 1) Lisp people just don't do it, for reasons lost in the mists of time,
> probably to do with small screens.
Yes. 1600x1200 is small, and it starts straining my visual acuity.
I need contacts. I mean, 4000x4000 contacts. And I'll still have to scroll
then.
Better make it an implant somewhere in the neocortex.
Charles Hixson
Michael Hudson wrote:
> "Anthony Cartmell" <AJCar...@csi.com> writes:
> -- snip
> > 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
I also find the stacked parenthesis notation difficult to read. But then
I'm also not a proficient Lisp programmer. I think that what we are
running into here is what field paleontologists and anthropologists call
"search image". One trains oneself to look for a particular kind of thing
(snail shells, to take the example I encountered) and after that the thing
one has trained for becomes increasingly easy to recognize. Others, who
have trained themselves to other patterns, won't see the snail shells, but
may well see something else (e.g., fossilized human skeletons).
Analogously, if one learns to read code in a particular way, one finds
reading code in that way increasingly easy. One who learns the C style
finds that way easier and more obvious than one who has learned the common
Lisp style. And vice versa. The problem is, mixing the styles of two
different languages is problematic. On at least on occasion I failed to
learn Lisp because it insisted that all variables were all-caps. Now
capitalized vs. mixed or lower rarely changes the meaning of things, BUT I
FIND IT VERY DISTASTEFUL WHEN EVERYTHING IS IN CAPS. I BELIEVE THAT THERE
WAS SOME WAY BESIDES INTERNING THE SYMBOLS TO REVERT TO MY PREFERRED FORM,
Mixed Case, but I didn't find it. Actually, my preferred form is a kind
of Java-ish form, with lots of mixed capitalization. I suppose, however,
that if I were to use Lisp very long, my search-image would change, and
then it would seem more reasonable to use underscores to separate words
rather than mixed case signals. But right now it looks very ugly. As do
Lots of Irritating Single Parenthesis. I believe that there used to be a
dialect of Lisp where one could signal "close all parenthesis back to the
root" by using a ] character, but that seems to have disappeared. I guess
that it may have been a bit error prone.
Pierre R. Mai
> 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?
But LISP IS DEAD, didn't you know that?
Fernando D. Mato Mira
(when (and (not (contains-p r code))
#-:series-plain (not (contains-p r prologs))
)
Fernando D. Mato Mira
> 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 was worried that in Australia the difficult thing would be to switch gears
with the left
hand, but it turned out to be OK.
I still wonder what's safer for right-handed drivers. I'm right handed, but for
one
hand on the steering wheel or the bike, the left one always felt right. But now
I feel the right is better to steer the car, and for the gearbox too!
Daniel Barlow
> 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
Because it attracts attention to the brackets, which Lisp programmers
have mostly learnt to ignore. The brackets are there as a service to
the editor so that it knows how to indent. The human pays attention
to the indentation. Highlighting the brackets is not a win.
Also because it takes up twice as much vertical space.
I see very little point in optimising layout for ease of editing with
editors that don't do bracket matching, as nobody wants to use one of
those anyway. If you don't have a worthwhile Lisp development
environment, your priorities will be different. Were I in that
situation, my priority would be getting a worthwhile Lisp development
environment
In summary, it looks ugly and it wastes space. And nobody really
cares about your need to use vi. And "apparently so strongly" because
comp.lang.lisp does _everything_ strongly.
-dan
Pierre R. Mai
> Analogously, if one learns to read code in a particular way, one finds
> reading code in that way increasingly easy. One who learns the C style
> finds that way easier and more obvious than one who has learned the common
> Lisp style. And vice versa. The problem is, mixing the styles of two
I actually think that one can train oneself to recognize and use
proficiently more than one indentation style, just as one can learn
to use different idioms in more than one human language (or computer
language). When I'm a Lisp programmer, I want to see
(defun map-query-for-effect (function query-expression database)
(multiple-value-bind (result-set columns)
(database-query-result-set query-expression database)
(when result-set
(unwind-protect
(do ((row (make-list columns)))
((not (database-store-next-row result-set database row))
nil)
(apply function row))
(database-dump-result-set result-set database)))))
whereas in C, I'm quite comfortable with:
static void EventLoop(void)
{
short err;
int formID;
FormPtr form;
EventType event;
do
{
EvtGetEvent(&event, 0);
/* Give System and Menu a chance to handle the event */
if (event.eType != keyDownEvent ||
(event.data.keyDown.chr!=hard1Chr &&
event.data.keyDown.chr!=hard2Chr &&
event.data.keyDown.chr!=hard3Chr &&
event.data.keyDown.chr!=hard4Chr))
if (SysHandleEvent(&event))
continue;
if (MenuHandleEvent((void *)0, &event, &err))
continue;
if (event.eType == frmLoadEvent)
{
formID = event.data.frmLoad.formID;
form = FrmInitForm(formID);
FrmSetActiveForm(form);
switch (formID)
{
case MainForm:
FrmSetEventHandler(form, MainFormHandleEvent);
break;
}
}
FrmDispatchEvent(&event);
} while(event.eType != appStopEvent);
}
Actually, I find that C needs much more whitespace to gain the same
amount of readability, at the loss of terseness. Note also that C
usually nests much less than Lisp, so you get longer but flatter
functions.
> Mixed Case, but I didn't find it. Actually, my preferred form is a kind
> of Java-ish form, with lots of mixed capitalization. I suppose, however,
> that if I were to use Lisp very long, my search-image would change, and
> then it would seem more reasonable to use underscores to separate words
> rather than mixed case signals. But right now it looks very ugly. As do
Using underscores to seperate words is indeed very ugly. That's why
no one does it in Lisp: Use hyphens: structure-editor, silly-function,
etc.
> Lots of Irritating Single Parenthesis. I believe that there used to be a
> dialect of Lisp where one could signal "close all parenthesis back to the
> root" by using a ] character, but that seems to have disappeared. I guess
> that it may have been a bit error prone.
It turned out that this functionality belongs in the editor, and not
the language. That's why ] will close all outstanding parentheses in
many Lisp modes. This way you get the benefits, without the trouble.
Try to ignore parens, and Lisp will turn into Lots of Indentation
Solves Paren-Proplems. ;)
Coby Beck
Anthony Cartmell <AJCar...@csi.com> wrote in message
news:8bnta8$im$2...@ssauraab-i-1.production.compuserve.com...
| 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?
|
I think you've seen all of the various objections and words of advice. It is basically
ugly (subjective) and an affectation of resistance to the functional style to which
lisp lends itself so well.
This, for example:
(defmethod duty-period-seq ((rday DTSC-reserve-day))
(crew-roster
(car (ground-duty-assignments
(duty-set-requirements
(reserve-duty-sets rday))))))
Is much cleaner, more compact and efficient code than this:
(defmethod duty-period-seq ((rday DTSC-reserve-day))
(crew-roster
(car
(ground-duty-assignments
(duty-set-requirements
(reserve-duty-sets rday)
)
)
)
)
)
)
There is *no* advantage to the dangling parenthesis, the indentation tells you
everything you need to know. If you don't have an indenting editor, you will still be
forced to count, dangling or not!
Coby
(ps Did you immediately spot the error? Which version is wrong?)
Coby Beck
Charles Hixson <charle...@earthlink.net> wrote in message
news:38DF97D9...@earthlink.net...
| Mixed Case, but I didn't find it. Actually, my preferred form is a kind
| of Java-ish form, with lots of mixed capitalization. I suppose, however,
| that if I were to use Lisp very long, my search-image would change, and
| then it would seem more reasonable to use underscores to separate words
| rather than mixed case signals.
Use dashes, not underscores.
cb
Hartmann Schaffer
"Anthony Cartmell" <AJCar...@csi.com> writes:
> ...
> I'm looking for reasons for *not* using one paren per line. So far I have:
> probably to do with small screens.
> layout style - "visual clutter".
> 3) Errr...
> 4) that's it.
>
> Can anyone extend my list?
3. with proper indentation, a separate line for each paren doesn't add
much useful information (at least for most people)
4. they waste vertical space (i like to see as much context as possible
because paging up and down (or flipping) pages distracts me: with a
separate line for each paren i get less context)
--
Hartmann Schaffer
Coby Beck
| I find that putting one paren per line gives me much useful information,
| based on its indentation position.
You earlier gave us to believe that one of your goals in dangling was ease of use in a
pure text editing environment.(?) To reiterate: indentation is *all* the information
you need. This along with judicious use of newlines will make your code enjoyable and
editable by all!
Coby
Hartmann Schaffer
>
> 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:
basically, you should use the style you are most comfortable with.
however, if you are working in a project and you have to cooperate with
several other people, it might be necessary to bow to a common standard
(depending on what you can negotiate with your coworkers). my guess is
that each language develops a style that is most comfortable for the
majority of people working in that language. if you tend to deviate
from that, it might be worthwhile to think about why. it's not
necvessarily wrong.
> ...
--
Hartmann Schaffer
Dorai Sitaram
Daniel Barlow <d...@telent.net> wrote:
>"Anthony Cartmell" <AJCar...@csi.com> writes:
>> 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
>
>editors that don't do bracket matching, as nobody wants to use one of
>those anyway. If you don't have a worthwhile Lisp development
>environment, your priorities will be different. Were I in that
>situation, my priority would be getting a worthwhile Lisp development
>environment
>
>In summary, it looks ugly and it wastes space. And nobody really
>cares about your need to use vi. And "apparently so strongly" because
>comp.lang.lisp does _everything_ strongly.
Hmm, both sides of this debate seem to agree that Vi
makes it difficult to use clumped parens. Actually, Vi
is as good as Emacs at paren matching (%) and at
s-expression manipulation (% combined with movement,
deletion, yanking, and insertion commands). I
use Vi and I use clumped parens.
Anthony prefers dangling parens for the positive reason
that it gives him some visual advantage. That he has
to use Vi sometimes is not relevant to his preference.
As he has said, he will use dangling parens even with
Emacs at his disposal.
Anyway, converting between the dangling and clumped
styles is automatable. An Elisp programmer should be
able to implement the following pseudocode in a few
minutes:
Dangling-to-clumped:
While there is a line with only right parens,
join that line with the previous line.
Reindent.
Clumped-to-dangling:
While there is a line ending in a right paren that
doesn't also have the corresponding left paren, move
that right paren into a new, following, line.
Reindent.
--d
Tom Breton
> > 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
>
> 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...
"So against" it is overstating the case. If I expect to insert more
stuff, fine, I leave a line.
However, stacked parents generally work out better for a few reasons:
Lisp code-blocks tend to be denser. Having 7 or 8 parentheses when
you close a function - mind you, not a big function, maybe 10-20 lines
- is not uncommon. Having 7 or 8 curly braces in C or C++ is very
rare and signals problems.
Something infix-syntax people usually don't understand: The
parantheses disappear. They are for the machine, not the user. The
indentation is for the user.
And of course the watering-hole effect amplifies the above.
--
Tom Breton, http://world.std.com/~tob
Not using "gh" since 1997. http://world.std.com/~tob/ugh-free.html
Rethink some Lisp features, http://world.std.com/~tob/rethink-lisp/index.html
Tom Breton
> "William Deakin" <wi...@pindar.com> wrote in message
> news:38DF492D...@pindar.com...
> > Anthony Cartmell wrote:
> >
> > > 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.
>
> 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.
That's enuff, you're trolling.
Tom Breton
> 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>).
It bears noting that Naggum's message in context was a non-sequitur.
Granted, it's an OK if bilious response to the strawman he was tilting
at in his own mind.
Gareth McCaughan
> 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?
I use the layout style you reject for two main reasons.
1. I like to be able to read other people's code, and
have other people able to read mine, with a minimum
of pain.
2. I like to be able to get a lot of code into a small
space; I can think about it much better that way.
I know that you don't think #1 is worth bothering about;
that's up to you. Let's look at #2.
Compare the following two code fragments.
(defun build-upward-closures ()
(loop for k from *maxplay* downto 0 do
(setf (aref *upward-closures* k)
(let ((result (ash 1 k)))
(loop for i from 0 below *n* do
(let ((k1 (logior k (ash 1 i))))
(when (> k1 k)
(setf result (logior result (aref *upward-closures* k1))))))
result))))
and
(defun build-upward-closures ()
(loop for k from *maxplay* downto 0 do
(setf (aref *upward-closures* k)
(let ((result (ash 1 k)))
(loop for i from 0 below *n* do
(let ((k1 (logior k (ash 1 i))))
(when (> k1 k)
(setf result (logior result (aref *upward-closures* k1)))
)
)
)
result
)
)
)
)
Each has 9 lines of code. The second also has 7 lines --
nearly as much again -- of pure noise. Those lines don't
tell me *anything*. They make it harder, not easier, to
tell what the line saying "result" is meant to be lined up
with, because my eyes aren't so good at checking alignment
over a distance of 6 lines as they are over a distance
of 4 lines. They don't serve to break up the code at
meaningful places; they don't clarify the code; they
are, as I say, pure noise.
Space in my editor windows is too precious to waste on
such things. I need it for code and comments and *meaningful*
separators.
And no, this doesn't mean that I'm using terrible cramped
windows and am trying to compensate by adopting a cramped
coding style. My emacs windows are 88 lines long.
*
There are times when I adopt the second style, very
locally: if, for instance, I have something like this:
(defvar foobie '(
("wibble spong" . 123)
("foo bar baz" . -99)
(#(1 2 3 4) . 'OUCH!)
)
Maybe your ICAD code consists mostly of things that
need frequent extending, like that. But if I had
tables of that kind, with structure nested several
layers deep, I'd go back to the "clumped" style;
space is too precious to waste.
--
Gareth McCaughan Gareth.M...@pobox.com
sig under construction
Joe Marshall
>
> 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?
>
Do whatever you want. I don't care. You're the one making a big deal
out of it.
Rahul Jain
27, 2000 6:31 AM, Daniel Barlow <d...@telent.net> wrote:
>
> In summary, it looks ugly and it wastes space. And nobody really
> cares about your need to use vi. And "apparently so strongly" because
> comp.lang.lisp does _everything_ strongly.
>
> -dan
FWIW, vim works fine for editing lisp:
:syntax on
:set autoindent
:set lisp
:set showmatch
Use % to find the matching paren... it even highlights matching parens in a
quoted list differently from normal ones: '(.....)
Not as powerful as emacs's manupulation, but v% works for selecting an
s-exp and [( and ]) for jumping to the start/end of the current one.
--
-> -\-=-=-=-=-=-=-=-=-=-/^\-=-=-=<*><*>=-=-=-/^\-=-=-=-=-=-=-=-=-=-/- <-
-> -/-=-=-=-=-=-=-=-=-=/ { Rahul -<>- Jain } \=-=-=-=-=-=-=-=-=-\- <-
-> -\- "I never could get the hang of Thursdays." - HHGTTG by DNA -/- <-
-> -/- http://photino.sid.rice.edu/ -=- mailto:rahul...@usa.net -\- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
Version 11.423.999.210020101.23.50110101.042
(c)1996-2000, All rights reserved. Disclaimer available upon request.
David J. Cooper
Ok, this post is somewhat ICAD-specific but i'm posting it here since
people on the ICAD mailing list are threatening to cancel their
subscriptions if they get any more dangling parens messages (what
a bunch of spoil-sports that list is!) and the ICAD-specific bits
should be pretty easy to follow for CL folks:
Anthony Cartmell wrote:
>
> 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.
>
Finally! This is where I was trying to steer this conversation when it started
on the ICAD user's group in the first place:
DJC:
>> None of your reasonings clarify why this is a good idea in *ICAD* but not
>> in *Common Lisp*. It sounds like you are trying to make a case for doing
>> dangling parens in Common Lisp. If you indeed want to make a case for
>> doing this in Common Lisp, may I cross-post your posting to comp.lang.lisp
>> and see what happens?
Anthony C:
> Sure thing, fire away. If you think it'll get us anywhere. I might find out
> why people are so against danglies.
That was a turning point of the conversation. In hindsight, it would have
been best to take the Common Lisp branch of the discussion here to c.l.l
immediately, and focus on ICAD-specific stuff in the ICAD mailing list.
As it turns out, we've worn out our welcome on the ICAD mailing list so
I guess we have to discuss the ICAD-specific stuff here now.
But there really isn't much ICAD-specific stuff to say anyway. As Anthony
says, an ICAD defpart is basically a list of lists of keywords, plists, and
lists. Things which in a normal CLOS program would be their own defmethods
end up as :inputs, :attributes, :parts, etc. within a defpart, for example:
(defpart assembly (base-html-sheet)
:optional-inputs
(
:sql-host nil
:login "dcooper8"
:password nil
:start-year 1900
:end-year 2100
)
:attributes
(
:year-numbers (list-of-numbers (the :start-year)
(the :end-year))
:number-of-years (length (the :year-numbers))
:current-time-value-list (multiple-value-list (get-decoded-time))
:year-to-index-hash-table (let ((ht (make-hash-table))
(count -1))
(dolist (year-number (the :year-numbers) ht)
(setf (gethash year-number ht) (incf count))))
:current-year-object (the (:years (gethash (sixth (the :current-time-value-list))
(the :year-to-index-hash-table))))
:update-handler (the :$$update-handler)
:application-root self
)
:descendant-attributes
(
:sql-host
:login
:password
)
:parts
((:$$update-handler :type 'add-event-handler)
(:years :type 'year
:quantify (:series (the :number-of-years))
;;
;; FLAG -- probably should do something to avoid
;; using nth here.
;;
:year-number (nth (the-child :index) (the :year-numbers)))
)
;;
;; FLAG -- should be redone as :writer-methods in a companion.
;;
:methods
((:write-descriptive-table-row
(&key (stream *output-stream*)
(target nil))
(let ((*output-stream* stream))
(with-table-row()
(with-table-cell()
(write-string "This is a snazzy calendar application.
MySQL data storage coming soon!" stream))
(with-table-cell()
(the (:write-self-link :display-string "Calendar" :target target))))))
(:write-html-sheet
(&key (stream *output-stream*))
(let ((*output-stream* stream))
(the :current-year-object (:write-html-sheet))))
))
Now, in the above example, I have partly done as Anthony is
advocating and dangled the final paren in each major list of
keywords, plists, or lists (in :optional-inputs, :attributes,
:descendant-attributes, :parts, and :methods).
This is a reasonable thing to do because of the long flat plists --
dangling that final paren makes it easier to add attributes or whatever,
and to remove the final ones.
Personally I do not use this style (I stack *all* parens without
exception), but I don't really have issues with the use of this style.
Beyond the defpart macro though, ICAD is really no different in
structure from CL (it is a strict superset of CL), so all the
expressions within each block can be considered as normal CL
and any defacto standards which apply to normal CL should apply
to them.
The single dingleberry at the end of each defpart section is the *only*
deviation from defacto CL style which is justifiable based on the
fact that we are using a defpart macro.
The only issue I *do* have with dangling even the final paren is the
danger that people might not draw the line there, and might use the
fact that "this is ICAD, not CL" as a license to begin putting
dingleberries anywhere and everywhere. That is why I will rarely
admit to the kosherness of even these end-of-section dingleberries
(so don't tell anyone i said it was ok, ok?)
>
> Yup, again, ICAD is different to Lisp, and seems to require different code
> layout.
>
Yup.
> > You could perhaps ask your (ICAD) Lisp code readers? Surely they are the
> > people that should have first say on this topic.
>
We have been through several gyrations on the Lisp users group and they
finally told us to go the hell outside and play. So we've come out here.
Yours,
-dave
P.S. ;;
;; Kill all dangling parens.
;;
(defun decruftify-buffer (arg)
(interactive "p")
(save-excursion
(goto-char (point-min))
(replace-regexp "[ \t\n]*)" ")")))
--
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
Anthony Cartmell
news:m3k8iof...@world.std.com...
> Lisp code-blocks tend to be denser. Having 7 or 8 parentheses when
> you close a function - mind you, not a big function, maybe 10-20 lines
> - is not uncommon. Having 7 or 8 curly braces in C or C++ is very
> rare and signals problems.
I think this is the solution to our discussion - thanks!
The "Lisp" code I write in ICAD is much more like C/C++ in that we construct
long relatively-shallow list structures. Thus adding code is mostly
inserting into lists, and dangling parens are useful and don't occur in long
sequences (perhaps three or four closes maximum in a row).
Pure Lisp seems to use much shorter, deeper list structures, so adding code
is more often wrapping forms around each other. Obviously if there are a
large number of nested forms the number of close parens is too many for
one-per-line, hence the style guide that says dangling parens are bad. Also
the need to insert stuff in the middle of lists is much less common.
My problem in understanding the Lisp convention was that I have never
programmed real Lisp, and so didn't understand the "shape" of a full-blown
Lisp application.
My thanks to everyone who posted opinions and information, it has been
interesting talking to you guys. Of course, if this post is still wrong I'd
love to hear why!
Cheers!
Rob Warnock
+---------------
| Hmm, both sides of this debate seem to agree that Vi
| makes it difficult to use clumped parens. Actually, Vi
| is as good as Emacs at paren matching (%) and at
| s-expression manipulation (% combined with movement,
| deletion, yanking, and insertion commands). I
| use Vi and I use clumped parens.
I agree. Clumped r-parens are no problem to Vi, and look a *lot* nicer.
And even though the newer "nvi" (which I use) lacks "lisp mode", it still
has "showmatch" and the paren-matched "%" movement. Granted, without "lisp
mode" the autoindent isn't ideal, but for me it's "good enough".
As Dorai says, Vi lets one cut & paste whole S-exprs easily enough --
"d%", move somewhere else, then "p" or "P" (then maybe insert or delete
a whitespace char).
-Rob
-----
Rob Warnock, 41L-955 rp...@sgi.com
Applied Networking http://reality.sgi.com/rpw3/
Silicon Graphics, Inc. Phone: 650-933-1673
1600 Amphitheatre Pkwy. PP-ASEL-IA
Mountain View, CA 94043
Rob Warnock
+---------------
| Espen Vestre wrote:
| > 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: [example omitted]
+---------------
Note that even Vi can do this, since it *can* "expr-indent" -- well,
actually "S-expr shift", but that's been "good enough" in my experience.
Simply ":set sw=1", put the cursor on the opening paren of the S-expr
you need to shift, and type ">%" (or "<%" if moveing left), and then
additional "."s as needed to line it all up. The entire S-expr, no matter
how many lines long, will move as one unit. [And yes, any bunched r-parens
at the end will move, too, which is usually what you want.]
Fernando D. Mato Mira
> (when (and (not (contains-p r code))
> #-:series-plain (not (contains-p r prologs))
> )
And here's maybe the biggest problem:
(and (or
....
)
For someone, the paren matches the and and is OK, for another one, even more
Pascal-like person, the expression is not properly closed:
(and (or
..
)
)
That said, for modeling component hierarchies, the dangling style seems to be the
right approach
(anyway, appart form the ocassional hack, one should normally use a modeler, not a
text-editor to generate/edit
them, but I still rather have a modeler generate those files in block form, just in
case I want to touch/look at them.
But of couse not for embedded code!)
Fernando D. Mato Mira
> (and (or
> ....
> )
> (and (or
> ..
> )
> )
Sorry. I used variable-width font before.
Fernando D. Mato Mira
> (defun build-upward-closures ()
> (loop for k from *maxplay* downto 0 do
> (setf (aref *upward-closures* k)
> (let ((result (ash 1 k)))
> (loop for i from 0 below *n* do
> (let ((k1 (logior k (ash 1 i))))
> (when (> k1 k)
> (setf result (logior result (aref *upward-closures* k1)))
> )
> )
> )
> result
> )
> )
> )
> )
>
> tell me *anything*. They make it harder, not easier, to
> tell what the line saying "result" is meant to be lined up
> with, because my eyes aren't so good at checking alignment
> over a distance of 6 lines as they are over a distance
> of 4 lines. They don't serve to break up the code at
> meaningful places; they don't clarify the code; they
> are, as I say, pure noise.
Is it just the distance? What about this:
(defun build-upward-closures ()
(loop for k from *maxplay* downto 0 do
(setf (aref *upward-closures* k)
(let ((result (ash 1 k)))
(loop for i from 0 below *n* do
(let ((k1 (logior k (ash 1 i))))
(when (> k1 k)
(setf result (logior result (aref *upward-closures* k1))))))
result))))
Floats 1 position to the right, but I don't get the same "Where the _heck_ does
this go?" feel.
Fernando D. Mato Mira
> this go?" feel.
Gee. In the above font it doesn't float at all!
[Netscape: WYGIWYG (or WYD, for not using a real NNTP client)]
Anthony Cartmell
"David J. Cooper" <dco...@genworks.com> wrote in message
news:38DFEB80...@genworks.com...
> Anthony Cartmell wrote:
> >
> > 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.
>
> Finally! This is where I was trying to steer this conversation when it
started
> on the ICAD user's group in the first place:
Errr...no, you simply stated that dangling parens in ICAD were, without
question, a bad layout style, and the main reason you cited was because
it was considered bad style in Lisp.
We have now agreed that ICAD is not Lisp, so that particular argument
against using dangling parens in ICAD is not valid.
> Now, in the above example, I have partly done as Anthony is
> advocating and dangled the final paren in each major list of
> keywords, plists, or lists (in :optional-inputs, :attributes,
> :descendant-attributes, :parts, and :methods).
>
> This is a reasonable thing to do because of the long flat plists --
> dangling that final paren makes it easier to add attributes or whatever,
> and to remove the final ones.
>
> Personally I do not use this style (I stack *all* parens without
> exception), but I don't really have issues with the use of this style.
Halleluia! We've reached some sort of agreement!! It's just down to the
nitty-gritty of when to stck and when to dangle. See the web site link
below for some ICAD layout examples.
> Beyond the defpart macro though, ICAD is really no different in
> structure from CL (it is a strict superset of CL), so all the
> expressions within each block can be considered as normal CL
> and any defacto standards which apply to normal CL should apply
> to them.
OK, but isn't it still a grey (or even gray) area with "cond" "case"
"let-stream" etc. which can have long shallow structures? You could apply
either argument here.
> The single dingleberry at the end of each defpart section is the *only*
> deviation from defacto CL style which is justifiable based on the
> fact that we are using a defpart macro.
Or, more accurately, based on the fact that we are closing a long shallow
structure, not a short deep one.
> The only issue I *do* have with dangling even the final paren is the
> danger that people might not draw the line there, and might use the
> fact that "this is ICAD, not CL" as a license to begin putting
> dingleberries anywhere and everywhere. That is why I will rarely
> admit to the kosherness of even these end-of-section dingleberries
> (so don't tell anyone i said it was ok, ok?)
Depends whether you want a rigid rule, or a "do whatever seems best" rule.
I've put some examples together on my web site for anyone who's interested.
http://ourworld.compuserve.com/homepages/AJCartmell/icadparens.html
Comments welcome!
Erik Naggum
| The "Lisp" code I write in ICAD is much more like C/C++ in that we
| construct long relatively-shallow list structures. Thus adding code is
| mostly inserting into lists, and dangling parens are useful and don't
| occur in long sequences (perhaps three or four closes maximum in a row).
you have previously given an example like this:
(list a
(list b c d)
(list 0
(list e f g
(list h))))
I didn't understand why you did this, as I would typically have written
it very differently, and much more compactly:
`(,a (,b ,c ,d) (0 (,e ,f ,g (,h))))
for what it's worth, I don't think editing this structure is hard, even
in vi-clones, which do sport the % command to move to the other paren.
on the other hand, I think a fair summary of the situation is that as you
grow used to Lisp and the parens lose importance and "disappear", you
seek tools that help you reduce the importance of the parens, too.
#:Erik
Fernando
<AJCar...@csi.com> wrote:
>Errr...no, you simply stated that dangling parens in ICAD were, without
>question, a bad layout style, and the main reason you cited was because
>it was considered bad style in Lisp.
So, if you agree that ICAD isn't lisp, why did you bring this
irrelevant thread here?
//-----------------------------------------------
// Fernando Rodriguez Romero
//
// frr at mindless dot com
//------------------------------------------------
Duane Rettig
> "Erik Naggum" <er...@naggum.no> wrote in message
> news:31630313...@naggum.no...
> > 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.
>
> 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.
It's because you haven't yet separated your IDL writing style from
your Lisp writing style. In further entries on this thread, it seems
you and David Cooper are coming to an agreement, but the agreement
seems uncertain; it looks to me more like a justification to continue
doing what each of you are doing, and not to understand where the real
problem lies. I don't know IDL (ICAD Design Language) myself, so I
asked the experts (people at KTI) and got an answer very quickly.
Results below.
> > 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.
I think you are influenced in your Lisp layout style by your IDL
style, so this statement would not quite be true. I could not have
argued this yesterday, but now that you are coming to the conclusion
that IDL is not Lisp, it's time to finish off this earlier argument.
> > 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.
Eight years sheds no light on a person's experience level. As a musician
since childhood, I was always taught the adage "Practice makes perfect",
but never got any good until I realized that the correct version of this
adage is "Perfect practice makes perfect." If you practice mistakes,
then you will only perfect the mistakes. What is the mistake here?
It is the mixing of Lisp layout style with IDL layout style.
> Does anyone know?
When in doubt, ask experts. I did, and got an answer from Stanley
Knutson of KTI, who gave me permission to post his answer.
He summarized the parenthesis question in a further email exchange
by saying:
>> As I said in the style guide, the only places where a single ) is good
>> is for closing a 'section' of the defpart.
Here is (most of) his original mail to me:
========
Duane,
Thanks for asking. ICAD style has been hottly debated about every two years
for the last 10+ years.
ICAD Defparts have their own needs that are not reflective of general lisp
usage.
In particular, a defpart has multiple sections for each attribute
and in a normal clos program, each of those attributes would have been a
separate
top-level function.
I've attached a short style guide that I've written for our internal use.
It reflects the basic style I've been using for a while.
At one point I tried to get something like this into our class or
documentation
but it was too controversial.
- Stanley
------=_NextPart_000_0008_01BF97DF.603B6670
Content-Type: application/octet-stream;
name="style-guide.text"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="style-guide.text"
ICAD defpart coding style suggestions
3/27/2000 Stanley Knutson
The goal is to enhance readability for large defparts
and to enable grep to find the DEFINITION of a method.
Example:
(defpart my-application (basic-application
base-spec-sheet-mixin
)
:part-documentation
(:description
"Why this part is useful"
:examples
"This shows how to use it:
<pre>
lisp code
</pre>
"
)
:inputs
(
:remark "child-object is required"
:CHILD-OBJECT
)
;; --------------------------------------------------
:attributes
(
:remark ":fancy-width uses the child to center something else"
:FANCY-WIDTH
(if (the :foo)
(if (the :bar)
(progn
(do-some-operation
with arguments)
))
;; else (not (the :foo))
(progn
(do something else
)))
;; the :%%internal-width is an intermediate
;; use ;; (not :remark) since it is not in the generated documentation
:INTERNAL-WIDTH
(+ (the :child-object :width) 30)
)
;; --------------------------------------------------
:pseudo-parts
(
(:MY-CHILD
:remark "Tell why my-child is useful.
This is given as a remark for the :type, that is how the
doc generator wants it."
:type my-child)
)
;; --------------------------------------------------
:methods
(
(:INITIALIZE-OUTPUT
(stream)
:remark "This method writes the first bit
to the output file"
(write-string "hi there" stream))
))
RULES:
1) CAPITALIZE the attribute, method and part names.
It makes them a bit easier to find,
and you can then grep for the capitalized names to find
the locations that define it.
2) Put a comment for almost evey attribute, part or method.
Use :remark if the comment should appear in the generated
reference documentation for this defpart.
3) Put a blank line between each defpart and attribute
4) The closing ) for each section of the defpart
is on a separate line,makes it easier to insert more stuff.
5) Separate the sections with ;;------ lines
6) Put the sections in this order usually:
inputs
optional-inputs
defaulted-inputs
modifiable-optional-inputs
modifiable-defaulted-inputs
modifiable-attributes
attributes
uncached-attributes
combination-attributes
parts
pseudo-parts
methods
7) the very end of the defpart can have the )) to close the last
section and the defpart on the same line.
8) Indent as per emacs ctrl-meta-q WITH THE ICAD INDENT RULES
we customize the Franz-lisp indentation rules to know about defparts.
(the lisp function is fi:indent-sexp)
9) You can group multiple closing )) on one line
but if the block is more than 5 or so lines,
add a ;; comment indicating what block is being closed.
{NOTE: exception rules #4 and #7}
10) name internal methods and defparts with %% so they don't
show up in the documentation or in the ICAD inspector by default.
11) Put one "logical unit" in a file: this usually means
just one defpart per file, with the file name the same as the defpart
name.
The exception is a set of several small closly-related functions.
In this case, they can be grouped into one file.
However, try to keep the file size under 500 lines.
If it is much bigger than that, you've probably got more than one
group of stuff in the same file, so it merits separation
into different bits.
12) Whenever possible, group the strings that customers will
want to customized into one file of defparameters.
In particular, *think* about what the customer might want to customize.
This will make it easier to document.
In many cases (icad browser for example), we actually ship this
file as part of the reference/example documentation.
As of R7.1, we now have a 'resource string' object
and each major module of ICAD should use that as much as possible
since it allows easier customization on a per-language basis
at runtime.
------=_NextPart_000_0008_01BF97DF.603B6670--
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 du...@Franz.COM (internet)
Duane Rettig
> 2. I like to be able to get a lot of code into a small
> space; I can think about it much better that way.
>
> I know that you don't think #1 is worth bothering about;
> that's up to you. Let's look at #2.
>
> Compare the following two code fragments.
>
> (defun build-upward-closures ()
> (loop for k from *maxplay* downto 0 do
> (setf (aref *upward-closures* k)
> (let ((result (ash 1 k)))
> (loop for i from 0 below *n* do
> (let ((k1 (logior k (ash 1 i))))
> (when (> k1 k)
> (setf result (logior result (aref *upward-closures* k1))))))
> result))))
>
> and
>
> (defun build-upward-closures ()
> (loop for k from *maxplay* downto 0 do
> (setf (aref *upward-closures* k)
> (let ((result (ash 1 k)))
> (loop for i from 0 below *n* do
> (let ((k1 (logior k (ash 1 i))))
> (when (> k1 k)
> (setf result (logior result (aref *upward-closures* k1)))
> )
> )
> )
> result
> )
> )
> )
> )
I've seen most of the style arguments based on philosophy posted
on this thread, but there is one argument I have not yet seen.
The most convincing argument for me to run with the first style is
what the lisp itself says:
user(1): (pprint '(defun build-upward-closures ()
(loop for k from *maxplay* downto 0 do
(setf (aref *upward-closures* k)
(let ((result (ash 1 k)))
(loop for i from 0 below *n* do
(let ((k1 (logior k (ash 1 i))))
(when (> k1 k)
(setf result (logior result (aref *upward-closures* k1)))
)
)
)
result
)
)
)))
(defun build-upward-closures ()
(loop for k from *maxplay* downto 0 do
(setf (aref *upward-closures* k)
(let ((result (ash 1 k)))
(loop for i from 0 below *n* do
(let ((k1 (logior k (ash 1 i))))
(when (> k1 k)
(setf result
(logior result
(aref *upward-closures* k1))))))
result))))
user(2):
In general, any lisp code that can be manipulated as data is
easier to work with if it matches the result of its pretty-printed
output. Now it is true that the pretty printer can be customized,
and thus you're not going to get exactly the same output if you
change, say, indentation rules and other attributes. But for all of
its customizability, I know of no way to tell the pretty-printer to
dangle its closing parens. Was this an oversight, or by design?
For Anthony Cartmell, I don't know IDL, and I've already posted
the opinion of an ICAD developer, but it seems to me that whether
or not IDL rules should allow for dangling parens should be weighed
heavily on whether or not a defpart is source-only, or whether it
is possible by any means to get hooks into the source (by way of
a code-walker, macroexpansion, or other debugging activity). If
the former, then it doesn't matter. If the latter, then unless
there have been extensions to ICAD's pretty-printer over CL's
printer, the intermediate forms will look "wrong", because they
will have no dangling parens.
Duane Rettig
> I'm looking for reasons for *not* using one paren per line.
I don't think that this is true. Your list below does not
reflect what you had been given at the time of your posting.
> 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?
Let's start with correcttions.
The first part of #1 has to do with de-facto standards. It is
perhaps interesting that almost every lisp programmer disagrees
on something about what lisp should be and do, especially when
dealing with style. However, it is precisely this tendency to
disagree that makes it so blatanttly obvious when we almost
entirely agree on the issue of dangling parens.
The last part of #1 has to do with screen real estate. Serious
question: Do you print out your lisp code on paper in order to
look at it? Or do you have a portrait terminal instead? Rules
of thumb in any language usually say that you shouldn't have much
more than a pagefull per function, so the question pertains to
your style of viewing code.
#2 looks more like what was said about parens giving no useful
information. I once read some assembler code from a newbie
programmer that had learned in school that comments must be
used as much as possible. I don't remember the architecture
that was used, but the code was unreadable because of the
clutter, e.g.
mov count,r10 ; Move count into register R10
add 1,r10,r10 ; Increment r10 by 1
b L4 ; Branch to L4
This programmer's code was full of useful comments like this...
A paren, useful to a compiler should be ignorable to a programmer,
just like a comment line, (sometimes) useful to a programmer,
should be made ignorable by a compiler. If you fail to add whatever
syntax is required to make a comment invisible to the compiler, the
compiler will barf, because it mistakes the comment for real code.
And if you fail to make parens invisible to the programmers, the
programmers barf, because they are mistaking the parens for real
code.
I will ignore your #3 and #4, and replace them with:
3) As I posted earlier in this thread, it is the strong opinion
of the lisp that right parens should not dangle. Just try to get
the lisp printer to print lisp forms with dangling parens; even
setting *print-right-margin* to 1 doesn't help...
4) Whenever I see lisp code for review, I look for both algorithmic
and/or implementational bugs based on what I see in the code. One
of the tools I use is to assess the programming level of the programmer
submitting the code. It involves many factors, most of which are
probably subliminal. But having thought about it for a day or so,
I can say that whenever I see dangling parens, it contributes to
one of two assessments: "newbie" or "careless". Note that careless
can apply to me as well; I sometimes see code that I have written
previously which is sloppily formatted, and it is the assessment I
give myself as I correct it.
Duane Rettig
> Let's start with correcttions.
=========================^^
Heh, heh, including my own!
Anthony Cartmell
> your Lisp writing style.
Actually it's David who wants to format ICAD with Lisp layout rules. I use
dangling parens.
> Eight years sheds no light on a person's experience level.
Except that they have more experience than someone with one year!
> If you practice mistakes,
> then you will only perfect the mistakes. What is the mistake here?
> It is the mixing of Lisp layout style with IDL layout style.
Agreed. I don't let any Lisp style guidelines get into my ICAD layout.
That was David's idea, and I have been trying to find out why he thought
that way.
Once we've decided that dangling close parens are
1) Good for long shallow lists, to allow easy insertion of items, and
2) Bad for short deep lists, because they take up too much space and don't
provide any benefit,
the required rules for ICAD seem obvious to me. There is some tweaking
possible of course, but the statement that "dangling parens are bad" really
doesn't apply to ICAD code.
I've put together some layout examples of some typical ICAD code for anyone
interested at
http://ourworld.compuserve.com/homepages/AJCartmell/icadparens.html .
Thanks for your comments!
Anthony Cartmell
> the opinion of an ICAD developer, but it seems to me that whether
> or not IDL rules should allow for dangling parens should be weighed
> heavily on whether or not a defpart is source-only, or whether it
> is possible by any means to get hooks into the source (by way of
> a code-walker, macroexpansion, or other debugging activity). If
> the former, then it doesn't matter. If the latter, then unless
> there have been extensions to ICAD's pretty-printer over CL's
> printer, the intermediate forms will look "wrong", because they
> will have no dangling parens.
ICAD is pretty much source-only (if I understand what you mean about being
able to print the thing to re-generate the source), as the real lisp code is
generated by the compiler from some fairly hefty macros, the main one being
defpart. As far as I know there is no way to generate the code for a
defpart created object from the Lisp object itself. You can view the code
in the ICAD browser but think that is done by storing fragments of source,
and I seem to remember it keeps the original layout. I may be wrong, it's
never seemed to me a very useful thing to do.
ICAD is really an fairly object-oriented language that just happens to be
based on Lisp. The basic structure of the code is proprietry, and it could
be implemented in any base language. The only places Lisp appears are in
expressions and function definitions.
An interesting angle on the discussion, thanks!
Dorai Sitaram
Well, the CLISP pretty-printer gives this "semi-dangled" output:
(defun build-upward-closures nil
(loop for k from *maxplay* downto 0 do
(setf (aref *upward-closures* k)
(let ((result (ash 1 k)))
(loop for i from 0 below *n* do
(let ((k1 (logior k (ash 1 i))))
(when (> k1 k)
(setf result (logior result (aref *upward-closures* k1)))
) ) )
result
) ) ) )
Ie, rparens are either on the same line as their
corresponding lparen, or they are clumped together on a
line of their own, where they line up (column-wise)
with an lparen above them. But if you look closer, you
will realize with a jolt that the lparen that an rparen
lines up with is _not_ its matching lparen... I guess
the rparens don't quite "disappear" as previous
articles advised, but they do fade into a
quantum-mechanical interchangeability, losing the
identity that we give to the more substantial parts of
the code.
(
(
(
) ) )
--d
Gareth McCaughan
[I said:]
>> They make it harder, not easier, to
>> tell what the line saying "result" is meant to be lined up
>> with, because my eyes aren't so good at checking alignment
>> over a distance of 6 lines as they are over a distance
>> of 4 lines. They don't serve to break up the code at
>> meaningful places; they don't clarify the code; they
>> are, as I say, pure noise.
>
> Is it just the distance? What about this:
>
>
> (defun build-upward-closures ()
> (loop for k from *maxplay* downto 0 do
> (setf (aref *upward-closures* k)
> (let ((result (ash 1 k)))
> (loop for i from 0 below *n* do
> (let ((k1 (logior k (ash 1 i))))
> (when (> k1 k)
> (setf result (logior result (aref *upward-closures* k1))))))
>
>
>
> result))))
>
> Floats 1 position to the right, but I don't get the same "Where the
> _heck_ does this go?" feel.
It's no easier for me than the version with intervening
rparens. I think it's just a matter of the distance.
David Hanley
dangling close paranthesis, though I am not a super lisp coder
by any means.
(defstruct person
name ; a string
address ; the person's street address
gender ; the symbol 'male or 'female if known, nil of otherwise
)
Otherwise, where does the paren go? Before the comment?
Inconsistent. Also, if you want to add a field, you just hop
to the end of the last field line, hit crtl-J and type away ( emacs ).
Often while editing and dubugging a function I'll leave naked
parens, then tighten them back in when I know it's perfect.
dave
David Hanley
"Fernando D. Mato Mira" wrote:
>
> 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
You got it backwards. The ones who do
if ( b ) {
foo()
} else {
bar();
}
are the ones who haven't learned to program yet.
:)
Tom Breton
Wow, a C true-indentation-style war here of all places! }:)
I'm in! I'm in! I'll be against K&R style.
David Hanley
Tom Breton wrote:
>
> Wow, a C true-indentation-style war here of all places! }:)
>
> I'm in! I'm in! I'll be against K&R style.
Great. But for clarity, we call that the "wrong" style.
dave
David Hanley
"Pierre R. Mai" wrote:
> "Anthony Cartmell" <AJCar...@csi.com> writes:
>
> > 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.
I don't think this is a valid argument Humans grow up using language
from birth and have it running through their heads every second of
their lives Also computer code requires much more accuracy while
spoken words an often be muddled through and imprecise which you
know especially well if you are married
The above is parodic in nature. You can still make out quite well
what it means with no punctuation, partially because of the many
levels of redundancy in spoken language. While lisp code:
defmethod play-move ttt tic-tac-toe move
let board board ttt setf square board move if = to-move ttt 1 'x 'o won? ttt
move switch-players ttt
Is unacceptable. You don't know if it's a specialized function or not, and if
so, on what,
you don't know what the parameters of the function are, etc.
Yes, editors can help you naviagte through code. But it is nuch more work to
navigate through code then format it so the eye can see it naturally, especially
when code is complex and under heavy development.
dave
Erik Naggum
| Lots of Irritating Single Parenthesis. I believe that there used to be a
| dialect of Lisp where one could signal "close all parenthesis back to the
| root" by using a ] character, but that seems to have disappeared. I
| guess that it may have been a bit error prone.
* Pierre R. Mai
| It turned out that this functionality belongs in the editor, and not the
| language. That's why ] will close all outstanding parentheses in many
| Lisp modes. This way you get the benefits, without the trouble. ...
for what it's worth, I have found it significantly easier to write code
in Emacs with M-( and M-) rather than ( and ). I guess I picked up that
habit when I wrote an SGML-mode that automatized the matching between
start- and end-tags and inserted every character of the element name in
_both_ the start- and the end-tag. I generalized this to let, e.g., M-*
produce ** with the cursor between them, and applied it to "", `', {},
[], <>, «», ¡!, ¿?, and for that old Common Lisp reader, ||, as well as
comments with #||#. in my view, it's a serious mistake to use paired
delimiters of any kind in a language without _actively_ supporting their
paired entry when writing.
#:Erik
Erik Naggum
| Sorry for the "newbie" question, but I thought that the indentation was
| based on the list structure, and not the other way round.
well, this gets a little complicated. the indentation is automatically
produced for you based on the list structure by the editor. the list
structure, however, becomes visually apparent to us humans through
indentation. new Lispers look at the list structure and think they
understand the indentation. old Lispers look at the indentation and
understand the list structure. new Lispers count parentheses and swear.
old Lispers reindent their code and immediately spot mistakes and just
clean them up. the whole Lisp enlightenment experience is about making a
fundamental swap between syntax and indentation. (at least one language
has made this switch permanent: python. I'm not sure this is a good
thing.)
| If the parens were based on the indentation then we wouldn't even need to
| use them.
this is very naive. _some_ redundancy is a fundamental characteristic of
_all_ successful communication, between computers as well as humans.
| 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.
that's because you have never let yourself get immersed in indentation.
you don't need to see the parentheses. (if you start seeing fnords,
alert your local illuminati.)
#:Erik
Erik Naggum
| I've seen most of the style arguments based on philosophy posted on this
| results of the pretty printer.]
I like this argument. I think we can sum it up like this:
there is no whitespace after an opening parenthesis.
there is no whitespace before a closing parenthesis.
this is the law. if you break it, it is not pretty.
#:Erik
thi
> 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.
for smashing fruit, a hammer is fine.
why do you smash fruit, what has it done to you?
thi
thi
> 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!
when one has confusion, why ask others about it?
surely you are the expert? can others be anything but entertaining?
thi
Gareth McCaughan
> Well, the CLISP pretty-printer gives this "semi-dangled" output:
..
> Ie, rparens are either on the same line as their
> corresponding lparen, or they are clumped together on a
> line of their own, where they line up (column-wise)
> with an lparen above them.
I use this style too, sometimes. I've never quite
worked out why :-).
> But if you look closer, you
> will realize with a jolt that the lparen that an rparen
> lines up with is _not_ its matching lparen...
This bothers me every time I use that style. Which
is one reason I don't do so very often.
Erik Naggum
| Well, the CLISP pretty-printer gives this "semi-dangled" output:
| But if you look closer, you will realize with a jolt that the lparen that
| an rparen lines up with is _not_ its matching lparen...
someone recently said (sorry, I have been skimming news lately) that he
had a problem starting with Lisp because everything was in uppercase --
small things like that can effectively block one's entry into new areas.
back when I was fairly new to Lisp (eons and eons ago, of course), I came
across CLISP and its unf<beep>ingbelievably braindamaged pretty printer.
it was immediately obvious that this had been implemented in a vacuum,
free from influence from all knowledgable programmers on the planet and
beyond, and it still sucked. to see code printed like this was such a
horrible experience I immediately seized upon the source code to try to
find out how to turn this gut-wrenching abomination off. but what did I
find? the entire source code was formatted like this! aaaaauuugh! and
everything in German, to boot. the abyss was staring back at me. <fade>
CLISP has since improved. no animals have been hurt in its production.
#:Erik
Erik Naggum
| 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 :)
* Anthony Cartmell
| Seems to me that this really is the main reason... is the Lisp layout
| "standard" really this sad?
there is another, deeper reason behind this that you may have overlooked.
in C, parentheses are used for a number of fundamentally different tasks,
and in C++ it gets _completely_ insane, but that's another matter. after
a student of C has learned the painful precedence rules by rote and is
still trying to internalize them so he can just _read_ expressions, the
parentheses enter the picture as a source of pain or a painkiller when
the precedence rules do not match the requirements of the expression.
either way, there is pain. you will often find C programmers battle
their operators and their precedence rules for hours on end, recompiling
frequently because they don't have an interactive environment, either.
the lesson learned by that vestige of primitive brain that keeps us from
sticking a hand into hot water the second time, is that parentheses are
painful. that a C programmer could have gotten rid of the pain by using
parentheses consistently around his operators and arguments is lost by
this primitive part of the brain.
then Lisp comes around and it's all parentheses. primitive brain shrieks.
this is probably not restricted to C, but a property of that horrible
mathematical infix syntax that is supposedly "natural" and which _also_
has precedence rules in which parentheses play an important role,
including the implied multiplication in the absence of operators. it
could be that early childhood experiences with the utter mindlessness of
infix syntax and the need for parentheses to escape out of the stupid
rules they made up is actually exceptionally traumatic on young brains
who try to trust their ability to understand the world around them.
parentheses break their trust, so when they see Lisp and it's all
parentheses, they become psychotic. this would explain a lot. a LOT!
however, the parentheses in Lisp are just like the semicolon in C.
here's an experiment you can conduct at home: take a piece of C code to
which a large group of people have contributed, several thousand lines of
Open Source should do, modify it slightly in some useful and non-trivial
way that people would probably like, and insert a newline before every
semicolon and indent the line an extra tab relative to the line it used
to belong to, ship the code to all the people who have contributed and be
very enthusiastic about your improvements, but don't comment on the style
change. if you do _not_ receive realistic death threats, consider the
experiment a failure.
#:Erik
Erik Naggum
| Anyway, converting between the dangling and clumped styles is
| automatable. An Elisp programmer should be able to implement the
| following pseudocode in a few minutes:
|
| Dangling-to-clumped:
| While there is a line with only right parens,
| join that line with the previous line.
| Reindent.
watch this code die a horrible flaming death:
(foo a ; mumble
b ; frotz
c ; fnord
)
#:Erik
Christopher Browne
>> It's because you haven't yet separated your IDL writing style from
>> your Lisp writing style.
>
>rules. I use dangling parens.
>
>
Eight years of practicing poor habits can lead to that "extensive
experience" being a downright Bad Thing.
I have one co-worker who has been programming in various languages for
quite a number of years who has a few such "bad habits" that make him
something a liability despite having extensive "experience."
For this reason, it is unsafe to generalize about the effects of
experience. *Valuable* experience is valuable; simply "spending time"
isn't.
--
"Bawden is misinformed. Common Lisp has no philosophy. We are held
together only by a shared disgust for all the alternatives."
-- Scott Fahlman, explaining why Common Lisp is the way it is....
cbbr...@ntlug.org- <http://www.ntlug.org/~cbbrowne/lsf.html>
Christopher Browne
>
>news:31630313...@naggum.no...
>> 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.
>
>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.
It's not that it's "such a bad layout style."
It's that if you're using a text editor that provides *any* support
for paren matching (just about anything better than MSFT WordPad), or
one that provides indentation support (e.g. - like Emacs), then
there's no *value* to having the parens dangle.
And if it's not really buying you anything, then the cost of having
less on the screen is a real cost, and *THAT* is the Bad Thing.
>> 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?
Because the extra lines and extra whitespace are a *distraction.*
Because screen space is *always* at a premium, regardless of how big
the screen is.
Wasting a line is a waste of a line, and wasting a whole line for one
lousy parenthesis is just plain silly. If you have a deeply nested
object, it's going to be followed by potentially a whole screen of
lines that have nothing more than a single parenthesis.
--
"Parentheses? What parentheses? I haven't noticed any parentheses
since my first month of Lisp programming. I like to ask people who
complain about parentheses in Lisp if they are bothered by all the
spaces between words in a newspaper..."
-- Kenny Tilton <ti...@liii.com>
cbbr...@hex.net- <http://www.hex.net/~cbbrowne/lisp.html>
Fernando D. Mato Mira
> I've put together some layout examples of some typical ICAD code for anyone
> interested at
> http://ourworld.compuserve.com/homepages/AJCartmell/icadparens.html .
>
> Thanks for your comments!
Try this:
"NEVER, NEVER, NEVER dangle a _single_ parentheses"
Even in VI it's easy to add an additional last form:
A <backspace> <enter> <hold space bar>
[I'm sure some vihead will have some better way to do the same]
--
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