From: David J. Cooper
Subject: Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <38DBE821.F64C2B22@genworks.com>
Hello,
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
·······@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
From: Fernando D. Mato Mira
Subject: Re: Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <38DD141F.DFDF14FF@iname.com>
An argument can be most easily settled if you manage
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
On Fri, 24 Mar 2000 22:10:28 GMT, "David J. Cooper" <·······@genworks.com>
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/
> 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 :)
Seems to me that this really is the main reason... is the Lisp layout
"standard" really this sad?
Cheers!
Anthony
------------------
Anthony Cartmell
Application Architect
New Design Paradigm
Worthing, England
Tel. +44 1903 201084
E-mail: ··········@csi.com
From: Erik Naggum
Subject: Re: Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <3163280191819937@naggum.no>
* Paolo Amoroso
| 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
From: Andrew K. Wolven
Subject: Re: Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <38DC6892.88B05F5C@redfernlane.org>
Lets have the compiler send an email to the X3J13 police, where it can be
corrected with immediate and overwhelming force.
"David J. Cooper" wrote:
> Hello,
>
> 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
> ·······@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
From: Christopher R. Barry
Subject: Re: Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <87vh2b1nwm.fsf@2xtreme.net>
"David J. Cooper" <·······@genworks.com> writes:
[...]
> 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
From: Reini Urban
Subject: Re: Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <38dcd2be.13610931@judy>
Christopher R. Barry wrote:
>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
From: David J. Cooper
Subject: Re: Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <38DE32C6.4E66D6A8@genworks.com>
Reini Urban wrote:
>
> 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.
Yours,
-dave
--
David J. Cooper Jr, Chief Engineer Genworks International
·······@genworks.com 5777 West Maple, Suite 130
(248) 932-2512 (Genworks HQ/voicemail) West Bloomfield, MI 48322-2268
(248) 407-0633 (pager) http://www.genworks.com
> The 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)
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: ··········@csi.com
From: David J. Cooper
Subject: Re: Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <38DE32F2.4EA927A9@genworks.com>
"Christopher R. Barry" wrote:
>
> "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,
-dave
--
David J. Cooper Jr, Chief Engineer Genworks International
·······@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
Hi there, I'm the guy you shouldn't waste time on, and I'm still interested
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?
Cheers!
Anthony
------------------
Anthony Cartmell
Application Architect
New Design Paradigm
Worthing, England
Tel. +44 1903 201084
E-mail: ··········@csi.com
From: Tim Bradshaw
Subject: Re: Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <ey38zz41uit.fsf@cley.com>
* Anthony Cartmell wrote:
> 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
> > 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.
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
Application Architect
New Design Paradigm
Worthing, England
Tel. +44 1903 201084
E-mail: ··········@csi.com
"Anthony Cartmell" <··········@csi.com> writes:
> 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.
--
Pierre Mai <····@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" <····@acm.org> wrote in message
···················@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
<snip>
> 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
------------------
Anthony Cartmell
Application Architect
New Design Paradigm
Worthing, England
Tel. +44 1903 201084
E-mail: ··········@csi.com
From: Coby Beck
Subject: Re: Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <954182977858@NewsSIEVE.cs.bonn.edu>
Anthony Cartmell <··········@csi.com> wrote in message
················@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?)
From: Joe Marshall
Subject: Re: Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <uity8m16h.fsf@alum.mit.edu>
"Anthony Cartmell" <··········@csi.com> writes:
>
> 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.
From: Erik Naggum
Subject: Re: Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <3163031395198264@naggum.no>
* David J. Cooper
| 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.
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
"Erik Naggum" <····@naggum.no> wrote in message
·····················@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?
Cheers!
Anthony
------------------
Anthony Cartmell
Application Architect
New Design Paradigm
Worthing, England
Tel. +44 1903 201084
E-mail: ··········@csi.com
From: Daniel Barlow
Subject: Re: Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <87pusgzjav.fsf@tninkpad.telent.net>
"Anthony Cartmell" <··········@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
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
In article <··············@tninkpad.telent.net>,
Daniel Barlow <···@telent.net> wrote:
>"Anthony Cartmell" <··········@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
>
>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.
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
From: Rob Warnock
Subject: Re: Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <8bp8ku$p3l3a$1@fido.engr.sgi.com>
Dorai Sitaram <····@goldshoe.gte.com> wrote:
+---------------
| 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 ····@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
From: Erik Naggum
Subject: Re: Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <3163280668120222@naggum.no>
* ····@goldshoe.gte.com (Dorai Sitaram)
| 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
In article <··············@tninkpad.telent.net> posted on Monday, March
27, 2000 6:31 AM, Daniel Barlow <···@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/ -=- ·················@usa.net -\- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
Version 11.423.999.210020101.23.50110101.042
(c)1996-2000, All rights reserved. Disclaimer available upon request.
Anthony Cartmell wrote:
> 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 ················@pobox.com
sig under construction
From: Fernando D. Mato Mira
Subject: Re: Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <38E08324.D173167F@iname.com>
Gareth McCaughan wrote:
> (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
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
Fernando D. Mato Mira wrote:
[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.
--
Gareth McCaughan ················@pobox.com
sig under construction
From: Fernando D. Mato Mira
Subject: Re: Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <38E083DA.789F907D@iname.com>
> Floats 1 position to the right, but I don't get the same "Where the _heck_ does
> 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)]
--
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
Gareth McCaughan <················@pobox.com> writes:
> 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 Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
From: Erik Naggum
Subject: Re: Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <3163275695429682@naggum.no>
* Duane Rettig <·····@franz.com>
| 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. [match the
| 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
> 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.
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!
Anthony
------------------
Anthony Cartmell
Application Architect
New Design Paradigm
Worthing, England
Tel. +44 1903 201084
E-mail: ··········@csi.com
In article <·············@beta.franz.com>,
Duane Rettig <·····@franz.com> wrote:
>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?
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
Dorai Sitaram wrote:
> 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.
--
Gareth McCaughan ················@pobox.com
sig under construction
> > 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 think it always lines up one character to the right of the open it matches
with. I think of it as ending a list of opens:
((sub-form)
(sub-form)
(sub-form)
(sub-form)
)
IMHO looks better than:
((sub-form)
(sub-form)
(sub-form)
(sub-form)
)
which sort-of leaves the last sub-form without anything following it...
Anthony
From: Fernando D. Mato Mira
Subject: Re: Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <38E1DE2A.6AA4FDF6@iname.com>
Anthony Cartmell wrote:
> > > 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 think it always lines up one character to the right of the open it matches
> with. I think of it as ending a list of opens:
It does look better, but do you realize the combinatorial explosion you get
in independently patched software?
...
(and (or
...
)
...
)
...
...
(and (or
...
)
...
)
...
...
(and (or
...
)
...
)
...
...
(and (or
...
)
...
)
...
...
(and (or
...
)
...
)
...
...
(and (or
...
)
...
)
...
...
(and (or
...
)
...
)
...
...
(and (or
...
)
...
)
...
...
(and (or
...
)
...
)
...
...
(and (or
...
)
...
)
...
...
(and (or
...
)
...
)
...
--
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
From: Erik Naggum
Subject: Re: Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <3163278794398146@naggum.no>
* Dorai Sitaram
| 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
From: William Deakin
Subject: Re: Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <38E1C8CF.CD1D3D9A@pindar.com>
Duane Rettig wrote:
> 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.
I hope this isn't a dis on philosophy and that there is more substance to the
arguments that have been put forward (although this in itself could be seen as a
philosophical assertion ;).
> The most convincing argument for me to run with the first style is
> what the lisp itself says...
This is, of course, a very good reason. And is a `why didn't I think of that' [1].
Thank you,
:) will
[1] However, the answer to this question is more clear: I'm too stupid :(
Gareth McCaughan wrote:
> 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!)
> )
I'm betting you didn't type this in a parenthesis-matching editor
because you need another close parenthesis to balance the expression.
You might be interested to see Erik's comments on the style of paren
placement exemplified about (which is optimized for editing with editors
that don't have S-expression navigation commands):
http://www.deja.com/=dnc/[ST_rn=ps]/getdoc.xp?AN=231406343&fmt=raw
--
Gareth Rees
Gareth Rees wrote:
> Gareth McCaughan wrote:
>> 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!)
>> )
>
> I'm betting you didn't type this in a parenthesis-matching editor
> because you need another close parenthesis to balance the expression.
You'd lose your bet. I *was* typing in a paren-matching
editor but I *wasn't* taking any notice of what it was
telling me. :-)
--
Gareth McCaughan ················@pobox.com
sig under construction
"Anthony Cartmell" <··········@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.
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: <················@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 <····@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]
From: Tom Breton
Subject: Re: Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <m3aejkf9qt.fsf@world.std.com>
····@acm.org (Pierre R. Mai) writes:
> 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: <················@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.
--
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
From: Erik Naggum
Subject: Re: Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <3163386232244478@naggum.no>
* Tom Breton <···@world.std.com>
| 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.
poor baby.
#:Erik
"Pierre R. Mai" <····@acm.org> wrote in message
···················@orion.dent.isdn.cs.tu-berlin.de...
> "Anthony Cartmell" <··········@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
------------------
Anthony Cartmell
Application Architect
New Design Paradigm
Worthing, England
Tel. +44 1903 201084
E-mail: ··········@csi.com
From: David Hanley
Subject: Re: Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <38E13CF8.B0536887@ncgr.org>
"Pierre R. Mai" wrote:
> "Anthony Cartmell" <··········@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
From: Erik Naggum
Subject: Re: Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <3163274599898094@naggum.no>
* "Anthony Cartmell" <··········@csi.com>
| 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
> | 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.)
This is the solution to the apparent problem:
ICAD does not use many deep nested lists, so large-multiple consecutive
close parens are fairly rare. ICAD does use long lists, so inserting and
removing items in lists is the main editing task, and dangling parens help
this. Thus it is now accepted in the ICAD community to use dangling parens,
with the recommendation that they only be used at the end of long list type
forms.
Lisp (as I now understand) uses many deep nested lists, and large-multiple
consecutive close parens are very common. Lisp does not tend to use long
list forms (except perhaps cond and case) so inserting removing items in
lists is not often done, and dangling parens therefore have little use.
For more information on why I dangle parens, see the web page I have put
together with some example ICAD code (note: not Lisp code).
http://ourworld.compuserve.com/homepages/AJCartmell/icadparens.html
David and I have come to a fairly close agreement on this issue - thanks to
all who responded with the Lisp side of the story.
Anthony
From: Erik Naggum
Subject: Re: Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <3163347243776063@naggum.no>
* "Anthony Cartmell" <··········@csi.com>
| Lisp (as I now understand) uses many deep nested lists, and large-multiple
| consecutive close parens are very common. Lisp does not tend to use long
| list forms (except perhaps cond and case) so inserting removing items in
| lists is not often done, and dangling parens therefore have little use.
um, excuse me, but what do you think Lisp code is made of? there is no
point at all to make the artificial differences you seem to want to make.
#:Erik
"Erik Naggum" <····@naggum.no> wrote in message
·····················@naggum.no...
> * "Anthony Cartmell" <··········@csi.com>
> | Lisp (as I now understand) uses many deep nested lists, and
large-multiple
> | consecutive close parens are very common. Lisp does not tend to use
long
> | list forms (except perhaps cond and case) so inserting removing items in
> | lists is not often done, and dangling parens therefore have little use.
>
> um, excuse me, but what do you think Lisp code is made of? there is no
> point at all to make the artificial differences you seem to want to
make.
>
um, excuse me, as far as I can tell Lisp code is made of many short, deeply
nested lists per file. ICAD code is made of one or two long shallow lists
per file. If I am wrong about Lisp source code's general form please
enlighten me!
There is plenty of point. Even some posters here admit to dangling parens
when ending a form that is long with variable numbers of items in it, such
as cond, case, etc.
You show me your Lisp code (I expect it'll have many consecutive close
parens and deeply nested short lists in it) and I'll show you some ICAD code
(Few cases where many consecutive close parens occur, shallow nested long
lists). Actually, you can see some ICAD code at
http://ourworld.compuserve.com/homepages/AJCartmell/icadparens.html, if you
haven't looked there already.
Anthony
From: Fernando D. Mato Mira
Subject: Re: Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <38E32FA5.A7F87CC0@acm.org>
Anthony Cartmell wrote:
> There is plenty of point. Even some posters here admit to dangling parens
> when ending a form that is long with variable numbers of items in it, such
> as cond, case, etc.
OK. This time I bite: There's no justtification for the last line or a cond or
case
not to be guarded by t, unless you really want to return NIL. Still, I never do
that.
I always explicitly write (t nil) if that's the case.
--
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
"Fernando D. Mato Mira" <········@acm.org> wrote in message
······················@acm.org...
> Anthony Cartmell wrote:
>
> > There is plenty of point. Even some posters here admit to dangling
parens
> > when ending a form that is long with variable numbers of items in it,
such
> > as cond, case, etc.
>
> OK. This time I bite: There's no justtification for the last line or a
cond or
> case
> not to be guarded by t, unless you really want to return NIL. Still, I
never do
> that.
> I always explicitly write (t nil) if that's the case.
How about ecase? Or other forms where there isn't a catch-all final form
that you can insert?
From: Fernando D. Mato Mira
Subject: Re: Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <38E38D9D.9D7B1E49@acm.org>
Anthony Cartmell wrote:
> How about ecase?
GNU
[I'm becoming a USENET psychic! ;)]
--
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
From: Erik Naggum
Subject: Re: Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <3163496120774411@naggum.no>
* "Anthony Cartmell" <··········@csi.com>
| um, excuse me, as far as I can tell Lisp code is made of many short, deeply
| nested lists per file.
that's, um, interesting. whence this shallow opinion that "Lisp code" is
sufficiently homogeneous to warrant such a blanket generalization?
| If I am wrong about Lisp source code's general form please enlighten me!
there seems to be so much to enlighten you about that it is instead much
more relevant at this point to use that fact to discredit your opinions.
this is regrettable, but your lack of insight into the topics you spend
so much time talking about renders any further discussion moot.
#:Erik
"Erik Naggum" <····@naggum.no> wrote in message
·····················@naggum.no...
> * "Anthony Cartmell" <··········@csi.com>
> | um, excuse me, as far as I can tell Lisp code is made of many short,
deeply
> | nested lists per file.
>
> that's, um, interesting. whence this shallow opinion that "Lisp code"
is
> sufficiently homogeneous to warrant such a blanket generalization?
Because some Lisp people get SO UPTIGHT about dangling parens, and because
of the examples people have posted here, and examples from text books. The
only reason people in the Lisp community don't generally allow dangling
parens is that they generally take up a lot of screen space for no general
reason. This occurs because they are generally writing code that generally
has large numbers of consecutive parens - in other words,
generally-speaking, deeply nested lists.
Yes it's a generalisation, but then so's "dangling parens are always bad".
If it's a poor generalisation please tell me a better one, if not then the
statement can stand as the main difference between Lisp and ICAD source code
forms.
> | If I am wrong about Lisp source code's general form please enlighten me!
>
> there seems to be so much to enlighten you about that it is instead much
> more relevant at this point to use that fact to discredit your opinions.
> this is regrettable, but your lack of insight into the topics you spend
> so much time talking about renders any further discussion moot.
Oh dear, I only asked whether my statement about Lisp code's general form
was correct or not. Is it really so difficult to reply without throwing all
your toys out of the pram and getting personal? Of the replies I've had in
this discussion I'd say about 10% have been non-abusive and useful. Of
course this is common on USENET, but I would have thought that
logical-thinking programming people would be able to have a sensible
discussion about things.
Cheers!
Anthony
From: Erik Naggum
Subject: Re: Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <3163582467115882@naggum.no>
* "Anthony Cartmell" <··········@csi.com>
| Because some Lisp people get SO UPTIGHT about dangling parens ...
:
| Oh dear, I only asked whether my statement about Lisp code's general form
| was correct or not. Is it really so difficult to reply without throwing all
| your toys out of the pram and getting personal?
your first line is indeed personal. my reply to you concerns a matter of
fact that is not personal, but relates only to your _actions_. yes, they
are _your_ actions, and if you want to take it personally, you are free
to do so for that reason, but you are equally free not to. how could
anyone _not_ take "some Lisp people get SO UPTIGHT" as a personal insult?
here's another _impersonal_ suggestion: grow a clue before you accuse
others of ills you are worse at yourself.
#:Erik
"Erik Naggum" <····@naggum.no> wrote in message
·····················@naggum.no...
> * "Anthony Cartmell" <··········@csi.com>
> | Because some Lisp people get SO UPTIGHT about dangling parens ...
> :
> | Oh dear, I only asked whether my statement about Lisp code's general
form
> | was correct or not. Is it really so difficult to reply without throwing
all
> | your toys out of the pram and getting personal?
>
> your first line is indeed personal. my reply to you concerns a matter
of
> fact that is not personal, but relates only to your _actions_. yes,
they
> are _your_ actions, and if you want to take it personally, you are free
> to do so for that reason, but you are equally free not to. how could
> anyone _not_ take "some Lisp people get SO UPTIGHT" as a personal
insult?
> here's another _impersonal_ suggestion: grow a clue before you accuse
> others of ills you are worse at yourself.
We must have different definitions of the word personal. In my dictionary
being personal is dealing with a particular person. My comment was very
general, not personal, as I was careful to say *some* Lisp people, as
opposed to *you*. Your comments aimed only at *me* were personal. If you
decide to include yourself in the *some* then I can't be blamed. If I had
wanted to get personal I would have said something like "Eric Naggum gets SO
UPTIGHT...", but I didn't.
Anthony
From: Jon S Anthony
Subject: Re: Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <38E94A6E.6536@synquiry.com>
Anthony Cartmell wrote:
>
> "Erik Naggum" <····@naggum.no> wrote in message
> ·····················@naggum.no...
> > * "Anthony Cartmell" <··········@csi.com>
> > | Because some Lisp people get SO UPTIGHT about dangling parens ...
> > :
> > | Oh dear, I only asked whether my statement about Lisp code's general
> form
> > | was correct or not. Is it really so difficult to reply without throwing
> all
> > | your toys out of the pram and getting personal?
> >
> > your first line is indeed personal. my reply to you concerns a matter
> of
> > fact that is not personal, but relates only to your _actions_. yes,
> they
> > are _your_ actions, and if you want to take it personally, you are free
> > to do so for that reason, but you are equally free not to. how could
> > anyone _not_ take "some Lisp people get SO UPTIGHT" as a personal
> insult?
> > here's another _impersonal_ suggestion: grow a clue before you accuse
> > others of ills you are worse at yourself.
>
> We must have different definitions of the word personal. In my
> dictionary being personal is dealing with a particular person. My
> comment was very general, not personal, as I was careful to say
> *some* Lisp people, as opposed to *you*. Your comments aimed only
> at *me* were personal. If you decide to include yourself in the
> *some* then I can't be blamed. If I had wanted to get personal I
> would have said something like "Eric Naggum gets SO UPTIGHT...", but
> I didn't.
Wow. That's some pretty impressive sophistry. Perhaps it would be of
some worth to you to consider entering one of the legal professions
and getting out of the software biz altogether.
/Jon
--
Jon Anthony
Synquiry Technologies, Ltd. Belmont, MA 02478, 617.484.3383
"Nightmares - Ha! The way my life's been going lately,
Who'd notice?" -- Londo Mollari
From: Jeffrey P. Sandys
Subject: Re: Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <38E38AC8.D00C3629@asme.org>
Anthony Cartmell wrote:
>
> ICAD does not use many deep nested lists, so large-multiple consecutive
> close parens are fairly rare. ICAD does use long lists, so inserting and
> removing items in lists is the main editing task, and dangling parens help
> this. Thus it is now accepted in the ICAD community to use dangling parens,
> with the recommendation that they only be used at the end of long list type
> forms.
We also use ICAD (which is Allegro CL with flavors type object oriented
macros added) but rely on the emacs editor to handle the S-expressions
(matched parenthesis).
ESC ··@ will mark the S-expression
ESC C-k will kill and S-expression
ESC C-f will move forward one S-expression
ESC C-b will move back one S-expression
Jeff Sandys
PS: Where is the ICAD newsgroup located?
"Anthony Cartmell" <··········@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 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
For more information on why I dangle parens, see the web page I have put
together with some example ICAD code (note: not Lisp code).
http://ourworld.compuserve.com/homepages/AJCartmell/icadparens.html
David and I have come to a fairly close agreement on this issue - thanks to
all who responded with the Lisp side of the story.
From: Andy Freeman
Subject: Re: Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <8btbto$6uh$1@nnrp1.deja.com>
> Sorry for the "newbie" question, but I thought that the indentation
> was based on the list structure, and not the other way round.
There are two audiences. The indentation and the white space is
for the most important audience, which uses parens to communicate
certain details to the less important audience. In other words,
"based on" reveals a gross misunderstanding of the purposes of
program elements.
I've been rereading Gabriel's "Patterns of Software". At the end
of subsection "The Quality Without a Name" in the first chapter,
there's a bullet-list of "features" found in quality software.
One of them is: "If it is small, it was written by an extraordinary
person, someone I would like as a friend; if it is large, it was not
designed by one person but over time in a slow, careful, incremental
way."
Part of that is whether the author did things to make life easy
for later human readers. While dangling } may be good for humans
reading C, it isn't good for people reading languages with more
reasonable syntaxes.
Ideosyncratic usage is merely a coward's way of expressing contempt
for readers. It shouldn't be surprising when they return the favor,
no matter how the initial contempt is argued.
-andy
Sent via Deja.com http://www.deja.com/
Before you buy.
"Andy Freeman" <······@earthlink.net> wrote in message
·················@nnrp1.deja.com...
> There are two audiences. The indentation and the white space is
> for the most important audience, which uses parens to communicate
> certain details to the less important audience. In other words,
> "based on" reveals a gross misunderstanding of the purposes of
> program elements.
As far as I understand it, the only way Emacs knows how to indent Lisp code
is by looking at the parentheses. Remove a parenthesis and the indentation
changes. Change the indentation and the parentheses remain. That's what I
meant by the indentation being based on the parentheses. I feel that there
has been a gross misunderstanding of what I meant, and I apologise for not
having been more explicit.
Of course you could argue that in some religious way the parens are based on
the indentation, but practically, at least in Emacs, I believe it's the
other way round. If in fact Emacs indents code based on its knowledge of
each possible form layout in Lisp, and if it ignores the parentheses then I
retract my statement as it obviously indicates "gross misunderstanding".
> Part of that is whether the author did things to make life easy
> for later human readers. While dangling } may be good for humans
> reading C, it isn't good for people reading languages with more
> reasonable syntaxes.
I'm glad you think dangling parens may be good for languages like C. For
the same reason we've decided that some dangling parens also may be good for
ICAD, a language based on Lisp.
"More reasonable" depends on your viewpoint - it's subjective.
> Ideosyncratic usage is merely a coward's way of expressing contempt
> for readers. It shouldn't be surprising when they return the favor,
> no matter how the initial contempt is argued.
The whole reason I took part in this discussion was that I didn't want to be
ideosyncratic! The problem stems from the fact that ICAD is not Lisp, and
it has different source code layout requirements to Lisp. In fact in some
ways it is more like C/C++.
See http://ourworld.compuserve.com/homepages/AJCartmell/icadparens.html for
more info.
Anthony
From: Fernando D. Mato Mira
Subject: Re: Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <38E323D5.7A2B5189@acm.org>
Anthony Cartmell wrote:
> ICAD is not Lisp
ICAD might not be Lisp but the language it uses is.
--
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
"Fernando D. Mato Mira" <········@acm.org> wrote in message
······················@acm.org...
> Anthony Cartmell wrote:
>
> > ICAD is not Lisp
>
> ICAD might not be Lisp but the language it uses is.
So?
The bits of ICAD that look like Lisp (function definitions, expressions)
could arguably be laid out with Lisp layout. But an ICAD application's
source is not at all like a Lisp application's source, and it can be more
easily edited and understood using a different layout. See
http://ourworld.compuserve.com/homepages/AJCartmell/icadparens.html if you
haven't already (do you agree with my implementation of your rule?).
Anthony
From: Fernando D. Mato Mira
Subject: Re: Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <38E38FFE.43A1928@acm.org>
Anthony Cartmell wrote:
> could arguably be laid out with Lisp layout. But an ICAD application's
> source is not at all like a Lisp application's source,
How so? That looks very much like a `file format' I designed for a certain VR
application
[Disclaimer: it's the first time I look at ICAD files]
> http://ourworld.compuserve.com/homepages/AJCartmell/icadparens.html if you
> haven't already (do you agree with my implementation of your rule?).
I had. Where are the versions including the additonal rule? [It's not "my
rule", BTW]
--
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
> > could arguably be laid out with Lisp layout. But an ICAD application's
> > source is not at all like a Lisp application's source,
>
> How so? That looks very much like a `file format' I designed for a certain
VR
> application
> [Disclaimer: it's the first time I look at ICAD files]
Lisp applications use many deeply nested forms, ICAD uses plists.
> > http://ourworld.compuserve.com/homepages/AJCartmell/icadparens.html if
you
> > haven't already (do you agree with my implementation of your rule?).
>
> I had. Where are the versions including the additonal rule? [It's not "my
> rule", BTW]
Sorry, failed to upload, it's there now. I only said "your rule" because
you were the one who pointed it out to me.
Cheers!
Anthony
From: Andy Freeman
Subject: Re: Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <8c03f1$9il$1@nnrp1.deja.com>
In article <············@ssauraaa-i-1.production.compuserve.com>,
"Anthony Cartmell" <··········@csi.com> wrote:
> As far as I understand it, the only way Emacs knows how to indent Lisp
code
> is by looking at the parentheses.
Like I said, you don't understand, and your explanation just makes
that misunderstanding more clear, as does your persistent use of
the phrase "based on". (The mistake is akin to arguing that program
structure is "based on" ASCII.)
> > Part of that is whether the author did things to make life easy
> > for later human readers. While dangling } may be good for humans
> > reading C, it isn't good for people reading languages with more
> > reasonable syntaxes.
>
> I'm glad you think dangling parens may be good for languages like C.
Um, I wrote nothing about dangling parens in C. Dangling parens in
C is also wrong except in the most extreme circumstances, circumstances
that are usually addressed better in some other way.
Dangling } makes sense in C because of C-specific issues with program
structure, issues which are not shared by languages with lisp-like
syntax, regardless of the semantics.
> "More reasonable" depends on your viewpoint - it's subjective.
Yup, opinions are like assholes - everyone has one, yet some stink
more than others. Subjective does not imply a lack of relative
merit.
> > Ideosyncratic usage is merely a coward's way of expressing contempt
> > for readers. It shouldn't be surprising when they return the favor,
> > no matter how the initial contempt is argued.
>
> The whole reason I took part in this discussion was that I didn't want
to be
> ideosyncratic!
Wrong. You've been arguing that your affectation is somehow laudable,
with an occasional retreat to "it's subjective" or "prove it".
You had a chance to learn from people who have written 100s of thousands
of lines in C/C++, lisp, and other languages, and you post sillyness
like "use a smaller font"[1] expecting to be taken seriously.
We've seen your examples, and they don't support your point.
-andy
[1] - I much prefer a white-board room, four walls of whiteboard,
to a large table for big design problems. Yes, there's no layering
and transport isn't good, but the persistence, area, and area/step
is better.
Sent via Deja.com http://www.deja.com/
Before you buy.
"Andy Freeman" <······@earthlink.net> wrote in message
·················@nnrp1.deja.com...
> In article <············@ssauraaa-i-1.production.compuserve.com>,
> "Anthony Cartmell" <··········@csi.com> wrote:
>
> > As far as I understand it, the only way Emacs knows how to indent Lisp
> code
> > is by looking at the parentheses.
>
> Like I said, you don't understand, and your explanation just makes
> that misunderstanding more clear, as does your persistent use of
> the phrase "based on". (The mistake is akin to arguing that program
> structure is "based on" ASCII.)
Perhaps you could explain to me how Emacs does indentation of Lisp code?
I'm really interested, especially if it doesn't look at the parens.
What should I have used instead of "based on"?
How about: ICAD is a language *written in* Lisp that provides an
object-oriented environment, using Lisp macros to define parts. The layout
of parts written using these macros shares some similarities with Lisp, but
have enough differences to warrant an ICAD-specific layout.
You can't just say "you don't understand" unless you explain why I'm wrong.
Unless you're trying to escape from losing the argument, but I'm sure you're
not trying to do that...
Cheers!
Anthony
From: Andy Freeman
Subject: Re: Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <8c0aas$hlv$1@nnrp1.deja.com>
In article <············@ssauraab-i-1.production.compuserve.com>,
"Anthony Cartmell" <··········@csi.com> wrote:
>> > Like I said, you don't understand, and your explanation just makes
> > that misunderstanding more clear, as does your persistent use of
> > the phrase "based on". (The mistake is akin to arguing that program
> > structure is "based on" ASCII.)
>
> Perhaps you could explain to me how Emacs does indentation of Lisp
Your persistence in asking the wrong question does not obligate
me to answer it. As I said, program structure serves a couple
of audiences. You're far too interested in irrelevant details
about the wrong audience and mistreat the right one.
> How about: ICAD is a language *written in* Lisp that provides an
> object-oriented environment, using Lisp macros to define parts.
And lisp provides an object-oriented environment, which may, or
may not, be implemented with lisp macros. According to this
argument, one shouldn't indent object-oriented lisp as one indents
lisp. Hmm.
> You can't just say "you don't understand"
Sure I can. You're trolling and I'm done.
-andy
Sent via Deja.com http://www.deja.com/
Before you buy.
"Andy Freeman" <······@earthlink.net> wrote in message
·················@nnrp1.deja.com...
> In article <············@ssauraab-i-1.production.compuserve.com>,
> "Anthony Cartmell" <··········@csi.com> wrote:
> > Perhaps you could explain to me how Emacs does indentation of Lisp
>
> Your persistence in asking the wrong question does not obligate
> me to answer it. As I said, program structure serves a couple
> of audiences. You're far too interested in irrelevant details
> about the wrong audience and mistreat the right one.
There's nothing wrong with my question. It obviously isn't one that you can
answer or would like to answer, otherwise you would have. Ho hum, I'll have
to find out somewhere else.
Thought for the day: what's the right question?
> > How about: ICAD is a language *written in* Lisp that provides an
> > object-oriented environment, using Lisp macros to define parts.
>
> And lisp provides an object-oriented environment, which may, or
> may not, be implemented with lisp macros. According to this
> argument, one shouldn't indent object-oriented lisp as one indents
> lisp. Hmm.
Possibly, it depends on the structure of the source code for the macros. It
might be possible to write Lisp macros to convert C++ source code into
Lisp - and then you'd probably want to lay the source out using C++
conventions (which seem to be much looser than the Lisp ones).
> > You can't just say "you don't understand"
>
> Sure I can. You're trolling and I'm done.
You can, but it doesn't progress the discussion, and it tends to make you
look silly.
Cheers!
Anthony
From: Lars Lundback
Subject: Re: Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <38E49C0F.E2C802C4@era.ericsson.se>
Anthony Cartmell wrote:
>
> > Your persistence in asking the wrong question does not obligate
> > me to answer it. As I said, program structure serves a couple
> > of audiences. You're far too interested in irrelevant details
> > about the wrong audience and mistreat the right one.
>
> There's nothing wrong with my question. It obviously isn't one that you can
> answer or would like to answer, otherwise you would have. Ho hum, I'll have
> to find out somewhere else.
I tried earlier to make you realize the difference between your
application domain and Lisp generally.
Your question is wrong in that "your" problem is not a problem in the
Lisp programming community, only that it might be one in your IDL
application programming world.
So yes, finding another audience is a good idea.
Regards, Lars
> Your question is wrong in that "your" problem is not a problem in the
> Lisp programming community, only that it might be one in your IDL
> application programming world.
The question was "how does Emacs work out indentation" and the answer is "by
looking at the parens" - as supplied by Erik.
Now then, what was so wrong about that question?
Anthony
From: Tim Bradshaw
Subject: Re: Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <ey3d7ob2bh9.fsf@cley.com>
* Anthony Cartmell wrote:
> The question was "how does Emacs work out indentation" and the answer is "by
> looking at the parens" - as supplied by Erik.
.. as well as other things:
(defun foo (x)
x)
(grible bar (x)
x)
(with-open-file ()
x)
(wibke-fron ()
x)
(loop for x from 0
below 100
if (evenp x)
collect x
into evens
else
collect x into odds
finally
(return (values evens odds)))
(loup for x from 0
below 100
if (evenp x)
collect x
into evens
else
collect x into odds
finally
(return (values evens odds)))
(I cheated on that last one -- no gnu emacs package I know can indent
loop that well, but zmacs can).
--tim
From: Erik Naggum
Subject: Re: Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <3163496610594768@naggum.no>
* "Anthony Cartmell" <··········@csi.com>
| Perhaps you could explain to me how Emacs does indentation of Lisp code?
| I'm really interested, especially if it doesn't look at the parens.
you're not getting it, are you? Emacs looks at the parens to indent, the
reader of the indented code subsequently does _not_ look at the parens.
unless you are Emacs, parens are nearly irrelevant. if you _are_ Emacs,
try M-x doctor.
#:Erik
From: David Thornley
Subject: Re: Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <iG8F4.1357$75.29260@ptah.visi.com>
In article <················@naggum.no>, Erik Naggum <····@naggum.no> wrote:
>* "Anthony Cartmell" <··········@csi.com>
>| Perhaps you could explain to me how Emacs does indentation of Lisp code?
>| I'm really interested, especially if it doesn't look at the parens.
>
> you're not getting it, are you? Emacs looks at the parens to indent, the
> reader of the indented code subsequently does _not_ look at the parens.
I think the point here is not the reader but the writer.
I type a lot of parens when I program in CL. That's one of the little
tasks that you just have to do. I don't make sure that the parens
match (except by using the editor's balancing commands). Another
way to express this is that I type parens to make the indentation come
out right, provided I'm working in the right tools (emacs or MCL).
Once I've written something and the editor has provided the indentation,
I pay no more attention to the parentheses, but look at the indentation.
It's sort of like working with LaTeX by fiddling with the definitions
until the paper looks right, or fiddling with HTML until the page looks
right (although in this case I have to be more aware of what I'm doing,
since the page might look horrible on another browser). The definitions
and HTML tags are not part of what I'm actually doing (which is to
create a paper or web page), but something I've got to get right to
make everything look nice.
It's the same with Lisp parens, except that it matters more if it
doesn't look right, since not looking right means it won't work.
--
David H. Thornley | If you want my opinion, ask.
·····@thornley.net | If you don't, flee.
http://www.thornley.net/~thornley/david/ | O-
"Erik Naggum" <····@naggum.no> wrote in message
·····················@naggum.no...
> * "Anthony Cartmell" <··········@csi.com>
> | Perhaps you could explain to me how Emacs does indentation of Lisp code?
> | I'm really interested, especially if it doesn't look at the parens.
>
> you're not getting it, are you? Emacs looks at the parens to indent,
the
> reader of the indented code subsequently does _not_ look at the parens.
> unless you are Emacs, parens are nearly irrelevant. if you _are_ Emacs,
> try M-x doctor.
Thanks for agreeing with me when I say that in Emacs the indentation is
based on the parens. That was all this particular point was about, if you
care to read back up the message tree...
"Andy Freeman" <······@earthlink.net> wrote in message
·················@nnrp1.deja.com...
> In article <············@ssauraaa-i-1.production.compuserve.com>,
> "Anthony Cartmell" <··········@csi.com> wrote:
>
> > As far as I understand it, the only way Emacs knows how to indent Lisp
> code
> > is by looking at the parentheses.
>
> Like I said, you don't understand, and your explanation just makes
> that misunderstanding more clear, as does your persistent use of
> the phrase "based on". (The mistake is akin to arguing that program
> structure is "based on" ASCII.)
So Andy is wrong when he said that I don't understand how Emacs indents
Lisp.
Cheers!
Anthony
From: Erik Naggum
Subject: Re: Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <3163690209543717@naggum.no>
* "Anthony Cartmell" <··········@csi.com>
| Thanks for agreeing with me when I say that in Emacs the indentation is
| based on the parens.
such has never been disputed. you're amazingly exasperating, you know that?
| So Andy is wrong when he said that I don't understand how Emacs indents
| Lisp.
well, I'm sorry, but you don't. as commonly used, "based on" indicates a
necessary condition but _not_ a sufficient one, and this is indeed the
case in this situation, as has been pointed out to you.
#:Erik
From: Andy Freeman
Subject: Re: Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <8c8d4t$10r$1@nnrp1.deja.com>
"Anthony Cartmell" <··········@csi.com>
> So Andy is wrong when he said that I don't understand how Emacs
indents
> Lisp.
Andy never wrote any such thing. Andy has pretty much ignored how
Emacs indents because, as he actually did write, it doesn't matter.
(Emacs could use other mechanisms and achieve the same result. Other
editors do.) If your best argument consists of making up positions
for your opponent....
Andy's comments can be summarized as "if you ask the wrong questions,
the answers don't help much". Cartwell's insistence on questions
with "based on" and Emacs are the wrong questions.
Emacs provides certain functionality because it is useful, but it
does not define "useful". Thus, we can't look to emacs as a guide
in certain areas, and we certainly can't read anything into its
implementation of certain operations which could have been implemented
in other ways.
-andy
Sent via Deja.com http://www.deja.com/
Before you buy.
"Erik Naggum" <····@naggum.no> wrote in message
·····················@naggum.no...
> * "Anthony Cartmell" <··········@csi.com>
> | Thanks for agreeing with me when I say that in Emacs the indentation is
> | based on the parens.
>
> such has never been disputed. you're amazingly exasperating, you know
that?
OK, so the original conversation between me and Andy Freeman went:
Me:
> 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.
Andy:
>Like I said, you don't understand, and your explanation just makes
>that misunderstanding more clear, as does your persistent use of
>the phrase "based on". (The mistake is akin to arguing that program
>structure is "based on" ASCII.)
> well, I'm sorry, but you don't. as commonly used, "based on" indicates
a
> necessary condition but _not_ a sufficient one, and this is indeed the
> case in this situation, as has been pointed out to you.
Yes, eventually, by Tim Bradshaw and Tim Moore (thanks Tims!). Had Andy
pointed out that more than *just* the parens was used by Emacs then I'd have
seen that my comment wasn't accurate. Sadly he only said "you don't
understand" which wasn't quite so helpful.
Actually, my original comment that indentation was based on parens still
stands as being correct. The fact is that it is also based on other things
too, but the parens are still necessary to define the structure.
Anthony
From: Andy Freeman
Subject: Re: Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <8caavo$34c$1@nnrp1.deja.com>
In article <············@ssauraac-i-1.production.compuserve.com>,
"Anthony Cartmell" <··········@csi.com> wrote:
> OK, so the original conversation between me and Andy Freeman went:
Cartwell then proceeds to quote things out of context, context
which shows that he's wrong.
Cartwell still hasn't figured out that one could design a lisp
editor which doesn't display parentheses at all, just as one
could design one which doesn't help with indentation. One
important difference is that one could be useful for the primary
audience, an audience that Cartwell has contempt for, while the
other isn't. Oh, and the possibility of the former pretty much
demolishes any argument that parens have the role that Cartwell
demands, but so did structure editors, which only display parens,
but, unlike emacs, don't use them in their internal representation.
However, we all know what the point of this exercise is. That's
why it's okay for him to make up positions for other people.
-andy
Sent via Deja.com http://www.deja.com/
Before you buy.
In article <············@nnrp1.deja.com>,
Andy Freeman <······@earthlink.net> wrote:
>
>Cartwell still hasn't figured out that one could design a lisp
>editor which doesn't display parentheses at all,
One can do this already. Just use your editor's
syntax-highlighting mechanism to make the parens
invisible. (E.g., in vim, :hi delimiter guifg=bg.)
It's an interesting experiment (I have conducted it on
myself). I boldly predict that the Lisp primary
audience will actually want the parens back as
the important peripheral visual aids that they are.
They may wish to "low-light" them, but they don't want
them gone completely. Indentation alone can't bear
the burden of making the code readable, just as parens
alone certainly can't.
On the other hand, indentation may be enough for
Anthony's ICAD code. Since it isn't deeply nested, it
will still remain readable (like shell script code), so
his one-per-line (now invisible!) parens buy him
nothing that he doesn't already have by virtue of
indentation. So he doesn't really need the parens, and
on top of that he indents them by themselves on
separate lines. That would be like a general
Lisper enclosing each stretch of indentation with
parenlike enclosers!
Anthony's detractors keep saying one doesn't look _at_
the parens, but that doesn't mean that one doesn't need
them to be around in one's visual field. Recall we
don't look _at_ the indents either, we are just
deriving a visual benefit from their being there.
Looking at anything involves deriving supporting
information, continuously and as needed, from
peripheral items we are not ostensibly looking at.
--d
>just as one
>could design one which doesn't help with indentation. One
>important difference is that one could be useful for the primary
>audience, an audience that Cartwell has contempt for, while the
>other isn't. Oh, and the possibility of the former pretty much
>demolishes any argument that parens have the role that Cartwell
>demands, but so did structure editors, which only display parens,
>but, unlike emacs, don't use them in their internal representation.
From: Tim Moore
Subject: Re: Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <8c2pht$8pp$0@216.39.145.192>
On 31 Mar 2000, Erik Naggum wrote:
> * "Anthony Cartmell" <··········@csi.com>
> | Perhaps you could explain to me how Emacs does indentation of Lisp code?
> | I'm really interested, especially if it doesn't look at the parens.
>
> you're not getting it, are you? Emacs looks at the parens to indent, the
> reader of the indented code subsequently does _not_ look at the parens.
> unless you are Emacs, parens are nearly irrelevant. if you _are_ Emacs,
> try M-x doctor.
I'm not sure why nobody wants to answer Anthony's question. Emacs does
use the parens, but it also looks at what's inside of them, and that is
more important for indentation. The point was made earlier in this
lengthy thread that Lisp parens are similar to C semi-colons; this bears
repeating on several levels. Semi-colons are a vital part of a C
program; the compiler depends on them to parse your code; if you get them
wrong your program can mean something completely different or nothing at
all; rarely do semi-colons appear anywhere but at the end of a line
(except in a for statement); no one would say that the placement of
semicolons is relevent to the human comprehension of a C program unless
they are placed in an eccentric way, and then they only serve to hinder
comprehension.
Replace everything I said about semi-colons in C with the Lisp equivalent
and maybe you'll start to see why Lisp programmers think that your
indentation style is whacky.
Clouding the issue somewhat is that C has another pair of symbols, {}, to
indicate block structure while Lisp goes back to parens again, but the
clouds part when one realizes that "block structure" is much less
important in Lisp than it is in C because expressions, statements and
"blocks" are all behave pretty much the same in Lisp and not at all in C.
To return to the question about Emacs, consider this little function:
(defun permutations (n r)
(labels ((perm-aux (n r)
(if (= n r)
1
(* n
(perm-aux (1- n) r)))))
(perm-aux n
(- n r))))
Emacs does use the parens to figure out containment of expressions. If it
only did that the function would be formatted like this:
(defun permutations (n r)
(labels ((perm-aux (n r)
(if (= n r)
1
(* n
(perm-aux (1- n) r)))))
(perm-aux n
(- n r))))
or, just as bad:
(defun permutations (n r)
(labels ((perm-aux (n r)
(if (= n r)
1
(* n
(perm-aux (1- n) r)))))
(perm-aux n
(- n r))))
Both these styles, which rely only on the parentheses for indentation,
would make a seasoned Lisp programmer vomit. The indentation of the first
example immediately says these things to the experienced reader, before
the individual symbols are absorbed by the brain: labels is a special
form, its first clause introduces bindings, the bindings in the first
clause behave like function definitions, perm-aux, if, *, 1-, and - are
are functions or "function-like" operators. All that information is lost
in the other two styles.
Now, I don't know if this has much bearing on whether or not your style is
valid, but I hope it illustrates why the Lisp Mafia is foaming at the
mouth and calling you names.
Tim
In article <············@216.39.145.192>,
Tim Moore <·····@herschel.bricoworks.com> wrote:
>I'm not sure why nobody wants to answer Anthony's question. Emacs does
>use the parens, but it also looks at what's inside of them, and that is
>more important for indentation....
>
>To return to the question about Emacs, consider this little function:
>(defun permutations (n r)
> (labels ((perm-aux (n r)
> (if (= n r)
> 1
> (* n
> (perm-aux (1- n) r)))))
> (perm-aux n
> (- n r))))
>
>Emacs does use the parens to figure out containment of expressions. If it
>only did that the function would be formatted like this:
>
>(defun permutations (n r)
> (labels ((perm-aux (n r)
> (if (= n r)
> 1
> (* n
> (perm-aux (1- n) r)))))
> (perm-aux n
> (- n r))))
>
>or, just as bad:
>
>(defun permutations (n r)
> (labels ((perm-aux (n r)
> (if (= n r)
> 1
> (* n
> (perm-aux (1- n) r)))))
> (perm-aux n
> (- n r))))
>
>Both these styles, which rely only on the parentheses for indentation,
>would make a seasoned Lisp programmer vomit.
Thank you for distinguishing the alternatives so well.
I like the last style best -- except for the `if'
and the `*', see below --, because it conserves
horizontal space too.
Traditional indenting (Emacs, say) by default
makes the second and subsequent lines of a list of code
indent past the head of the list (with the usual
exceptions), forcing you to take explicit action when
you want the indentation to be the parsimonious 2
spaces. I think the defaulting should be the other way
around. Consider
;style I
(a-symbol-with-a-ponderously-large-name exp1 ...
expj ...)
vs
;style II
(a-symbol-with-a-ponderously-large-name exp1 ...
expj ...)
I prefer style II. Indeed, it saves vertical space too
because one tends to break the code in style I
across more lines because there is less horizontal
space to put all the subexpressions in.
Here is the approach, in some detail. In general, the
indentation would be style II, with the following
exceptions:
1. When the head of the list is itself a list.
The second line lines up with the lparen (as in
Emacs):
(let ((x y)
(z ...
2. When the head of the list is a symbol of length
less than 3. The second line lines up past the head
(as in Emacs). This covers `if', `or', `*', and
any user-defined operator that is less than 3 long:
(if 1
2 ...
3. When the head of the list is explicitly billed as an
exception, e.g., `cond'. The second line lines up pas
the head (as in Emacs):
(cond (a b)
(c d) ...
Anything else (including what the user comes up with)
will get the standard 2-space indent by default (unlike
Emacs), but you can bill it as an exception using
the same mechanism as (3).
I've been using this style with no ill effect. (My
co-coders can't tell that anything is different.) It
gives indents that, while not quite the two
"vomitworthy" styles you list, is nevertheless
different from your norm. How bad is this approach
(in terms of relative milliliters of vomit generated)?
Any disadvantages?
--d
From: Tim Moore
Subject: Re: Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <8c311o$1mp$0@216.39.145.192>
On 31 Mar 2000, Dorai Sitaram wrote:
> Thank you for distinguishing the alternatives so well.
> I like the last style best -- except for the `if'
> and the `*', see below --, because it conserves
> horizontal space too.
>
> Traditional indenting (Emacs, say) by default
> makes the second and subsequent lines of a list of code
> indent past the head of the list (with the usual
> exceptions), forcing you to take explicit action when
> you want the indentation to be the parsimonious 2
> spaces. I think the defaulting should be the other way
> around. Consider
>
> ;style I
>
> (a-symbol-with-a-ponderously-large-name exp1 ...
> expj ...)
>
> vs
>
> ;style II
>
> (a-symbol-with-a-ponderously-large-name exp1 ...
> expj ...)
>
> I prefer style II. Indeed, it saves vertical space too
> because one tends to break the code in style I
> across more lines because there is less horizontal
> space to put all the subexpressions in.
That seems fine. However, I'd probably exploit the emacs default and put
the first argument on the next line:
(a-symbol-with-a-ponderously-large-name
exp1 ...
expj ...)
This gets a different indentation from the usual two spaces, which
indicates that something's up, that this is not a usual body.
>
> Here is the approach, in some detail. In general, the
> indentation would be style II, with the following
> exceptions:
>
> 2. When the head of the list is a symbol of length
> less than 3. The second line lines up past the head
> (as in Emacs). This covers `if', `or', `*', and
> any user-defined operator that is less than 3 long:
>
> (if 1
> 2 ...
Distinguishing short symbols like this seems confusing to me.
> 3. When the head of the list is explicitly billed as an
> exception, e.g., `cond'. The second line lines up pas
> the head (as in Emacs):
>
> (cond (a b)
> (c d) ...
>
> Anything else (including what the user comes up with)
> will get the standard 2-space indent by default (unlike
> Emacs), but you can bill it as an exception using
> the same mechanism as (3).
>
> I've been using this style with no ill effect. (My
> co-coders can't tell that anything is different.) It
> gives indents that, while not quite the two
> "vomitworthy" styles you list, is nevertheless
> different from your norm. How bad is this approach
> (in terms of relative milliliters of vomit generated)?
> Any disadvantages?
I'm hardly the arbitrator of Lisp taste, having been out of the game for
many years. However, I'm inclined to give extrordinary things special
indentation. For example, if I wrote my own with-... macro I'd customize
the indentation so that the binding clause was indented specially to make
it like the with-... macros already in the language. That would change
your rule 3 to be "Anything the user comes up with that's not a function
might get special indentation."
More generally, my inclination would be to always make my code look like
what's in CLtL2, but maybe I'm just showing my age.
Tim
From: Andy Freeman
Subject: Re: Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <8c3uak$f6f$1@nnrp1.deja.com>
In article <················@naggum.no>,
Erik Naggum <····@naggum.no> wrote:
> you're not getting it, are you? Emacs looks at the parens to indent,
I just remembered that there are/were editors that didn't look
at paretheses because they edited cons cells directly.
-andy
Sent via Deja.com http://www.deja.com/
Before you buy.
From: Tim Bradshaw
Subject: Re: Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <ey3wvmi0ynq.fsf@cley.com>
* Andy Freeman wrote:
> I just remembered that there are/were editors that didn't look
> at paretheses because they edited cons cells directly.
SEdit was one.
--tim
On Thu, 30 Mar 2000 19:17:25 +0100, "Anthony Cartmell" <··········@csi.com>
wrote:
> Perhaps you could explain to me how Emacs does indentation of Lisp code?
It's explained in the Emacs manual and in the ELisp source code of
Lisp/Scheme modes.
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
"Anthony Cartmell" <··········@csi.com> writes:
> "Erik Naggum" <····@naggum.no> wrote in message
> ·····················@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 ·····@Franz.COM (internet)
> It's because you haven't yet separated your IDL writing style from
> 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
------------------
Anthony Cartmell
Application Architect
New Design Paradigm
Worthing, England
Tel. +44 1903 201084
E-mail: ··········@csi.com
From: Fernando D. Mato Mira
Subject: Re: Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <38E1D09D.A3369087@iname.com>
Anthony Cartmell wrote:
> 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
"Fernando D. Mato Mira" <········@iname.com> wrote in message
······················@iname.com...
> Anthony Cartmell wrote:
>
> > 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]
I'll add it to the page - although the people who are most against dangling
parens in ICAD seem to agree that dangling the single paren at the end of
each section's lisp in a defpart is OK, as this is where things need to be
inserted. I don't think the number of dangling parens matters, it's the
type of form that they close that matters (deep and short, or long and
shallow).
Anthony
From: Fernando D. Mato Mira
Subject: Re: Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <38E328B9.C58103AA@acm.org>
Anthony Cartmell wrote:
> "Fernando D. Mato Mira" <········@iname.com> wrote in message
> ······················@iname.com...
> > Anthony Cartmell wrote:
> >
> > > 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]
>
> I'll add it to the page - although the people who are most against dangling
> parens in ICAD seem to agree that dangling the single paren at the end of
> each section's lisp in a defpart is OK, as this is where things need to be
> inserted. I don't think the number of dangling parens matters, it's the
> type of form that they close that matters (deep and short, or long and
> shallow).
A couple things:
1. I meant <left-arrow>, but someone might actually prefer to <backspace> and
retype a )
2. I meant dangling at the _beginning_ too.
The number of parens matterns in the sense that 1 closing saves you only a
left-arrow;
and an opening a right if there's nothing before it [This could be justified
except for the fact
that it's actually in the interest of your customer to get XEmacs for NT (or
whatever) installed'
I'm notorious at `infecting' every silly PC I have to touch with cygwin
(usertools only), Xemacs,
rcs+cvs, in that order, as needed].
--
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
Centuries ago, Nostradamus foresaw a time when Anthony Cartmell would say:
>> It's because you haven't yet separated your IDL writing style from
>> 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!
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....
········@ntlug.org- <http://www.ntlug.org/~cbbrowne/lsf.html>
> For this reason, it is unsafe to generalize about the effects of
> experience. *Valuable* experience is valuable; simply "spending time"
> isn't.
Ah, yes, but all my experience is *valuable*. Sorry I didn't say that
explicitly.
Methinks we've lost the point...
Centuries ago, Nostradamus foresaw a time when Anthony Cartmell would say:
>
>"Erik Naggum" <····@naggum.no> wrote in message
>·····················@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 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 <····@liii.com>
········@hex.net- <http://www.hex.net/~cbbrowne/lisp.html>
For more information on why I dangle parens, see the web page I have put
together with some example ICAD code (note: not Lisp code).
http://ourworld.compuserve.com/homepages/AJCartmell/icadparens.html
David and I have come to a fairly close agreement on this issue - thanks to
all who responded with the Lisp side of the story.
From: Fernando D. Mato Mira
Subject: Re: Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <38DE1648.A4AFA073@iname.com>
"David J. Cooper" wrote:
> 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
--
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
> 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...
Cheers!
Anthony
------------------
Anthony Cartmell
Application Architect
New Design Paradigm
Worthing, England
Tel. +44 1903 201084
E-mail: ··········@csi.com
From: Tom Breton
Subject: Re: Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <m3k8iofapg.fsf@world.std.com>
"Anthony Cartmell" <··········@csi.com> writes:
> > 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" <···@world.std.com> wrote in message
···················@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!
Anthony
------------------
Anthony Cartmell
Application Architect
New Design Paradigm
Worthing, England
Tel. +44 1903 201084
E-mail: ··········@csi.com
From: Erik Naggum
Subject: Re: Summary of Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <3163239343709562@naggum.no>
* Anthony Cartmell
| 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
"Erik Naggum" <····@naggum.no> wrote in message
·····················@naggum.no...
> 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))))
Just to save bandwidth and typing (it was an example not a real structure) -
think of the letters and numbers as bigger list items. The one-line layout
you use above is no different from the where-do-insert issue, which has been
covered quite well already.
For an example of what ICAD code looks like with different layout rules,
including "never dangle", see
http://ourworld.compuserve.com/homepages/AJCartmell/icadparens.html
Cheers!
Anthony
From: William Deakin
Subject: Re: Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <38DF41EB.86BA71D7@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.
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
"William Deakin" <·····@pindar.com> wrote in message
······················@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!
Anthony
------------------
Anthony Cartmell
Application Architect
New Design Paradigm
Worthing, England
Tel. +44 1903 201084
E-mail: ··········@csi.com
"Anthony Cartmell" <··········@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 ······@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
"Anthony Cartmell" <··········@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!
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)
"Espen Vestre" <·····@*do-not-spam-me*.vestre.net> wrote in message
···················@wallace.nextel.no...
> "Anthony Cartmell" <··········@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!
>
> Read it again.
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
------------------
Anthony Cartmell
Application Architect
New Design Paradigm
Worthing, England
Tel. +44 1903 201084
E-mail: ··········@csi.com
In article <············@ssauraac-i-1.production.compuserve.com>,
"Anthony Cartmell" <··········@csi.com> writes:
> ...
>> Read it again.
>
> 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
"Anthony Cartmell" <··········@csi.com> writes:
> 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)
From: Fernando D. Mato Mira
Subject: Re: Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <38DF8046.B1CE617F@iname.com>
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:
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.
--
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
From: Rob Warnock
Subject: Re: Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <8bp9mm$pc2nj$1@fido.engr.sgi.com>
Fernando D. Mato Mira <········@iname.com> wrote:
+---------------
| 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.]
-Rob
-----
Rob Warnock, 41L-955 ····@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
"Fernando D. Mato Mira" <········@iname.com> wrote in message
······················@iname.com...
> 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:
Exactly the point. Lisp does seem to mostly wrap things around other
things, rather than create lists of things. Perhaps it should have been
called Wrap not Lisp? :-)
Anthony
From: William Deakin
Subject: Re: Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <38DF492D.78533365@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.
> 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
"William Deakin" <·····@pindar.com> wrote in message
······················@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.
> > 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!
Anthony
------------------
Anthony Cartmell
Application Architect
New Design Paradigm
Worthing, England
Tel. +44 1903 201084
E-mail: ··········@csi.com
From: Joe Marshall
Subject: Re: Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <un1nkmksg.fsf@alum.mit.edu>
"Anthony Cartmell" <··········@csi.com> writes:
> 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?
"Joe Marshall" <·········@alum.mit.edu> wrote in message
··················@alum.mit.edu...
> "Anthony Cartmell" <··········@csi.com> writes:
>
> > 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?
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
------------------
Anthony Cartmell
Application Architect
New Design Paradigm
Worthing, England
Tel. +44 1903 201084
E-mail: ··········@csi.com
From: Fernando D. Mato Mira
Subject: Re: Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <38DFA052.72CE8B90@iname.com>
Anthony Cartmell wrote:
> 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!
--
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
From: Tom Breton
Subject: Re: Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <m3g0tcfakp.fsf@world.std.com>
"Anthony Cartmell" <··········@csi.com> writes:
> "William Deakin" <·····@pindar.com> wrote in message
> ······················@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, 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
From: Tim Bradshaw
Subject: Re: Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <ey33dpcxwzd.fsf@cley.com>
* Anthony Cartmell wrote:
> 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
From: William Deakin
Subject: Re: Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <38DF816D.4DB52AF2@pindar.com>
Anthony Cartmell wrote:
> > 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
From: Lars Lundback
Subject: Re: Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <38DF8C7F.C2FDB46@era.ericsson.se>
Anthony Cartmell wrote:
>
>
> 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
"Lars Lundback" <·············@era.ericsson.se> wrote in message
·····················@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.
Anthony
------------------
Anthony Cartmell
Application Architect
New Design Paradigm
Worthing, England
Tel. +44 1903 201084
E-mail: ··········@csi.com
From: David J. Cooper
Subject: Re: Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <38DFEB80.EA3AF2DD@genworks.com>
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
·······@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
"David J. Cooper" <·······@genworks.com> wrote in message
······················@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!
Anthony
------------------
Anthony Cartmell
Application Architect
New Design Paradigm
Worthing, England
Tel. +44 1903 201084
E-mail: ··········@csi.com
On Tue, 28 Mar 2000 13:58:08 +0100, "Anthony Cartmell"
<··········@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
//------------------------------------------------
From: Robert Monfera
Subject: Re: Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <38EADFBA.528FFB0D@fisec.com>
"David J. Cooper" wrote:
> But there really isn't much ICAD-specific stuff to say anyway.
[...]
> (defpart assembly (base-html-sheet)
>
> :optional-inputs
> (
> :sql-host nil
> :login "dcooper8"
> :password nil
> :start-year 1900
> :end-year 2100
> ) [...]
> )
I never use dangling parens in CL except for a few times I sinned, when
editing lengthy CLOS class definitions. (Incidentally, I think class
slot definitions would most naturally fit in a tabular, spreadsheet-like
form, given the limited and repetitive nature of exercising slot
options.)
> [...] final paren makes it easier to add attributes or whatever,
> and to remove the final ones.
Based on
http://ourworld.compuserve.com/homepages/AJCartmell/icadparens.html by
Anthony and the above comment, the only benefit to dangling parens is
easier subexpression addition and removal. It could perfectly be done
by the editor. Maybe it is trivial for emacs experts to do this (cursor
between characters is indicated as #\|):
1. Automatic closing paren addition:
(|)
(defclass|)
(defclass foo (|))
etc.
2. Automatic paren tucking:
(defclass foo ()
((bar :initarg :bar))
(baz :initarg :baz)))
Delete sexp:
(defclass foo () (defclass foo ()
((bar :initarg :bar)) OR (|
|)) (baz :initarg :baz)))
Instant magic:
(defclass foo ()
((bar :initarg :bar))|)) OR with baz, respectively
Would it solve the problem that is the only justification for dangling
parentheses? What's the best practice for erasing extra spaces now?
Thinking it forward, automatic transitions like
(defclass foo ()
((bar :initarg :bar))|))
Then user adds new exp:
(defclass foo ()
((bar :initarg :bar))(|)))
Magic:
(defclass foo ()
((bar :initarg :bar))
(|)))
To help achieve
(defclass foo ()
((bar :initarg :bar))
(baz :initarg :baz)))
could be obtained by describing indentation standards for functions,
like
(defindent defun
(name :same-line)
(lambda-list :same-line)
(body :fresh-line))
(defindent defclass
(name :same-line)
(superclasses :same-line)
(slot-definitions :fresh-line
:subexpressions ((slot-definitions :fresh-line))))
(defindent defindent
(name :same-line)
(parameters :fresh-line
:subexpressions ((parameters :fresh-line))))
There is some similar descriptive mechanism already, evidenced by DEFUN
et al not indented this way:
(defun foo (x y)
(bar x x)
(baz y x))
Robert
"Anthony Cartmell" <··········@csi.com> writes:
> 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
"Anthony Cartmell" <··········@csi.com> writes:
> > 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
From: Charles Hixson
Subject: Re: Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <38DF97D9.C9626DAB@earthlink.net>
Michael Hudson wrote:
> "Anthony Cartmell" <··········@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.
Charles Hixson <············@earthlink.net> writes:
> 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. ;)
Regs, Pierre.
--
Pierre Mai <····@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]
From: Erik Naggum
Subject: Re: Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <3163273489398038@naggum.no>
* Charles Hixson
| 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
From: Coby Beck
Subject: Re: Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <954183732352@NewsSIEVE.cs.bonn.edu>
Charles Hixson <············@earthlink.net> wrote in message
······················@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
From: Tim Bradshaw
Subject: Re: Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <ey34s9s1tz6.fsf@cley.com>
* Anthony Cartmell wrote:
> 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
"Tim Bradshaw" <···@cley.com> wrote in message
····················@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
------------------
Anthony Cartmell
Application Architect
New Design Paradigm
Worthing, England
Tel. +44 1903 201084
E-mail: ··········@csi.com
Anthony Cartmell wrote:
> <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 ···@cra.com
Charles River Analytics (617) 491-3474 x574
Cambridge, MA, USA http://www.cra.com/
From: Tim Bradshaw
Subject: Re: Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <ey3snxcwdrw.fsf@cley.com>
* Anthony Cartmell wrote:
> 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).
From: Fernando D. Mato Mira
Subject: Re: Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <38DF9708.D7DCB71F@iname.com>
Anthony Cartmell wrote:
> 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.
--
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
In article <············@ssauraab-i-1.production.compuserve.com>,
"Anthony Cartmell" <··········@csi.com> writes:
> ...
> 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?
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
From: Coby Beck
Subject: Re: Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <954184038390@NewsSIEVE.cs.bonn.edu>
Anthony Cartmell <··········@csi.com> wrote in message
·················@ssauraab-i-1.production.compuserve.com...
| 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
"Anthony Cartmell" <··········@csi.com> writes:
> 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 Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
Duane Rettig <·····@franz.com> writes:
> Let's start with correcttions.
=========================^^
Heh, heh, including my own!
--
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 ·····@Franz.COM (internet)
From: Joe Marshall
Subject: Re: Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <uvh28mqk2.fsf@alum.mit.edu>
"Anthony Cartmell" <··········@csi.com> writes:
> 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
Joe Marshall <·········@alum.mit.edu> writes:
> 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?
Regs, Pierre.
--
Pierre Mai <····@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]
From: Fernando D. Mato Mira
Subject: Re: Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <38DF6134.2B501576@iname.com>
Anthony Cartmell wrote:
> > 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?
--
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
"Fernando D. Mato Mira" <········@iname.com> wrote in message
······················@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
<snip>
> 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!
Anthony
------------------
Anthony Cartmell
Application Architect
New Design Paradigm
Worthing, England
Tel. +44 1903 201084
E-mail: ··········@csi.com
From: Fernando D. Mato Mira
Subject: Re: Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <38DF955F.5528CCDF@iname.com>
Anthony Cartmell wrote:
> 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
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
From: Fernando D. Mato Mira
Subject: Re: Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <38DF9DB4.5345E062@iname.com>
Just crossing the kind of thing where I'm not comfortable with myself either way:
(when (and (not (contains-p r code))
#-:series-plain (not (contains-p r prologs))
)
--
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
From: Fernando D. Mato Mira
Subject: Re: Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <38E07FD8.6CFE18B8@iname.com>
"Fernando D. Mato Mira" wrote:
> (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
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
From: Fernando D. Mato Mira
Subject: Re: Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <38E0804F.1B95CE43@iname.com>
"Fernando D. Mato Mira" wrote:
> (and (or
> ....
> )
> (and (or
> ..
> )
> )
Sorry. I used variable-width font before.
--
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
> Just crossing the kind of thing where I'm not comfortable with myself
either way:
>
> (when (and (not (contains-p r code))
> #-:series-plain (not (contains-p r prologs))
> )
Yup, this is the sort of layout question we get in ICAD more often than you
guys get in Lisp.
From: Fernando D. Mato Mira
Subject: Re: Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <38E32BA2.D5E5BEBF@acm.org>
Anthony Cartmell wrote:
> > Just crossing the kind of thing where I'm not comfortable with myself
> either way:
> >
> > (when (and (not (contains-p r code))
> > #-:series-plain (not (contains-p r prologs))
> > )
>
> Yup, this is the sort of layout question we get in ICAD more often than you
> guys get in Lisp.
Yes, except that I don't feel good about it. In fact, consistently with what
others said before,
this underlied thiking "Man, I hope this letification stuff is really useful.
I hate adding gratuitous
overhead and complicating the code. It doesn't work yet."
I didn't realize about the 2(3) Pascal-like matching rules until I got
confused because it seemed
to match the NOT. Now the stuff works, and it's been confirmed it can actually
help, so the paren ismoving
up. [In fact, it would in any case since I got enlightened at how wrong this
really was by this thread]
--
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
From: David Hanley
Subject: Re: Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <38E11D9D.987957A6@ncgr.org>
"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.
:)
From: Tom Breton
Subject: Re: Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <m3pusen1fk.fsf@world.std.com>
David Hanley <···@ncgr.org> writes:
> "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.
Wow, a C true-indentation-style war here of all places! }:)
I'm in! I'm in! I'll be against K&R style.
--
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
From: David Hanley
Subject: Re: Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <38E13A17.90811121@ncgr.org>
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
From: Fernando D. Mato Mira
Subject: Re: Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <38E1D3B0.36AE4B5A@iname.com>
class Foo
{
...
inline some_type whatever() const
{
return whatever;
}
<repeat 20 times>
}
class Foo
{
...
inline some_type whatever() const {
return whatever;
}
<repeat 20 times>
}
3 code + 1 space. That's 25% wasted space in your "right version"
[20% if a _useful_ coment line is added on top of each]
This is shorter, but might be harder to read:
class Foo
{
...
inline some_type whatever() const { return whatever;}
<repeat 20 times>
}
You can all throw up now ;->
--
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
From: David Hanley
Subject: Re: Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <38E25F82.A7930BB7@ncgr.org>
"Fernando D. Mato Mira" wrote:
>
> 3 code + 1 space. That's 25% wasted space in your "right version"
> [20% if a _useful_ coment line is added on top of each]
And? My hard drive is not going to get overfull because of this
"wasted" space.
dave
Centuries ago, Nostradamus foresaw a time when David Hanley would say:
>"Fernando D. Mato Mira" wrote:
>> 3 code + 1 space. That's 25% wasted space in your "right version"
>> [20% if a _useful_ coment line is added on top of each]
>
>And? My hard drive is not going to get overfull because of this
>"wasted" space.
Your *screen* will get overfull, and a 21" screen is considerably more
expensive than a 19" one, and bigger ones are more exorbitant still...
--
When I die, I'd like to go peacefully in my sleep like my grandfather,
not screaming in terror like his passengers...
········@ntlug.org- <http://www.ntlug.org/~cbbrowne/lsf.html>
From: Fernando D. Mato Mira
Subject: Re: Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <38E32CC6.DF546485@acm.org>
Christopher Browne wrote:
> Centuries ago, Nostradamus foresaw a time when David Hanley would say:
> >"Fernando D. Mato Mira" wrote:
> >> 3 code + 1 space. That's 25% wasted space in your "right version"
> >> [20% if a _useful_ coment line is added on top of each]
> >
> >And? My hard drive is not going to get overfull because of this
> >"wasted" space.
>
> Your *screen* will get overfull, and a 21" screen is considerably more
> expensive than a 19" one, and bigger ones are more exorbitant still...
Yes. A Sony Jumbotron is really expensive. The ones made up of all those
independent boxes are much better, but the dot pitch isn't great yet ;)
--
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
From: David Hanley
Subject: Re: Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <38E37E41.289677F7@ncgr.org>
Christopher Browne wrote:
> Centuries ago, Nostradamus foresaw a time when David Hanley would say:
> >"Fernando D. Mato Mira" wrote:
> >> 3 code + 1 space. That's 25% wasted space in your "right version"
> >> [20% if a _useful_ coment line is added on top of each]
> >
> >And? My hard drive is not going to get overfull because of this
> >"wasted" space.
>
> Your *screen* will get overfull, and a 21" screen is considerably more
> expensive than a 19" one, and bigger ones are more exorbitant still...
So? If there's too much to fit one screen, I can have that special
page-down key fitted. :) If I have lots of functions much longer than one
screen, I think that's a problem.
dave
From: Fernando D. Mato Mira
Subject: The Screen Is Not Enough (was: Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <38E39854.55596A9D@acm.org>
David Hanley wrote:
> So? If there's too much to fit one screen, I can have that special
> page-down key fitted. :) If I have lots of functions much longer than one
> screen, I think that's a problem.
Look at the Series source. An incredibly high percentage of the functions
have a single call site in the whole program. Pedantically, they should be
FLETs.
Why not if they could be practically traced while debugging, I could test
subfuctions
from the listener, and the editor supported outlining? That adds quite a lot
of lines,
even if subforms are closed:
(defun foo ()
(flet ....
(flet ....
(flet ....
(flet ....
<current foo code>)))))
I imagine one would want to display something like this:
(defun foo ()
(flet ....
> (flet ....
> (flet ....
> (flet ....
<current foo code>)))))
--
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
From: Tom Breton
Subject: Re: The Screen Is Not Enough (was: Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <m3g0t8dm62.fsf@world.std.com>
"Fernando D. Mato Mira" <········@acm.org> writes:
>
> Look at the Series source. An incredibly high percentage of the functions
> have a single call site in the whole program. Pedantically, they should be
> FLETs.
> Why not if they could be practically traced while debugging, I could test
> subfuctions
> from the listener, and the editor supported outlining?
In recent emacs, try M-x hs-minor-mode for exactly that.
--
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
"Christopher Browne" <········@news.hex.net> wrote in message
··························@news4.giganews.com...
> Centuries ago, Nostradamus foresaw a time when David Hanley would say:
> >"Fernando D. Mato Mira" wrote:
> >> 3 code + 1 space. That's 25% wasted space in your "right version"
> >> [20% if a _useful_ coment line is added on top of each]
> >
> >And? My hard drive is not going to get overfull because of this
> >"wasted" space.
>
> Your *screen* will get overfull, and a 21" screen is considerably more
> expensive than a 19" one, and bigger ones are more exorbitant still...
Try a font 25% smaller?
From: Tim Bradshaw
Subject: Re: Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <ey3u2ho4ntm.fsf@cley.com>
* Anthony Cartmell wrote:
> Try a font 25% smaller?
There is *no* screen that is big enough. That's the point.
"Tim Bradshaw" <···@cley.com> wrote in message
····················@cley.com...
> * Anthony Cartmell wrote:
>
> > Try a font 25% smaller?
>
> There is *no* screen that is big enough. That's the point.
>
Wow! You guys really are writing complicated code!
Centuries ago, Nostradamus foresaw a time when Anthony Cartmell would say:
>"Tim Bradshaw" <···@cley.com> wrote in message
>····················@cley.com...
>> * Anthony Cartmell wrote:
>>
>> > Try a font 25% smaller?
>>
>> There is *no* screen that is big enough. That's the point.
>
>Wow! You guys really are writing complicated code!
No, this is a basic rule of economics:
More is always preferable than less.
If I can see more useful information on screen, that is always better
than seeing less useful information on screen.
Back in the days when I did auditing, it was ascertained that there
was no table that was too big to be usefully completely covered with
paper. That extended up to boardroom tables 10m x 2m in size; the
ability to have a Whole Lot Of Stuff Showing At Once was *never* a
disadvantage. Eventually there's diminishing returns as it takes
too long to walk from one end of the table to the other.
If I could have a screen on the wall sized at 2m square, that would
probably not be as useful a formfactor as one 2m wide, with 1m of
height at around eye level. Based on present technologies, that
kind of screen would probably cost more than my car, and I can't
justify having such. Until I get that aspect of "enough," it is
reasonably valuable to preserve the very limited amount of space
available on a 17" or 19" screen.
--
"All language designers are arrogant. Goes with the territory..."
-- Larry Wall
········@hex.net - - <http://www.hex.net/~cbbrowne/lsf.html>
On Thu, 30 Mar 2000 14:01:31 GMT, ········@knuth.brownes.org (Christopher
Browne) wrote:
> If I can see more useful information on screen, that is always better
> than seeing less useful information on screen.
I agree. To appreciate how important screen real estate may become, try
writing Scheme code for LispMe (such fun :) running on a 3Com Palm
handheld:
http://www.lispme.de/lispme/
At first I thought that a monospaced font may be better because it makes
entering and editing code easier, but it seems that a proportional font
allows me to pack more characters in those tiny lines of text.
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
From: William Deakin
Subject: Re: Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <38E360C7.7CB3ACE1@pindar.com>
Christopher Browne wrote:
> More is always preferable than less.
Yes. Ask any small child `do you want the small ice-cream or the big
ice-cream?' and its pretty clear what the answer would be. However, I would
prefer fewer rather than more boils on my nose, say ;)
;) will
From: William Deakin
Subject: Re: Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <38E362A7.C5725523@pindar.com>
It is much against my better judgement to rise to this but...
Anthony Cartmell wrote:
> Tim wrote:
> > * Anthony Cartmell wrote:
> > > Try a font 25% smaller?
> >
> > There is *no* screen that is big enough. That's the point.
>
> Wow! You guys really are writing complicated code!
I spent 2-years (in the not so distant past) working on a vt100 (24x80)
with vi and it then becomes very very clear the importance of cutting
down on the visual clutter, number of lines in code blocks and
indentation styles. I challenge anybody who has a similar experiences to
say smart things like `why don't you reduce the font 25%' or `the number
of extra lines caused by dopey formatting isn't important.'
Thank-you-very-much and good night,
:) will
ps: As this irked me (again) I think I should share this calming story:
`Nan-in received a university professor who came to inquire about
enlightenment.
Nan-in served tea. He poured his visitor's cup full, and then kept on
pouring.
The professor watched the overflow until he could not restrain himself.
"Stop! No more will go in!"
"Like this cup", Nan-in said, "you are full of your own opinions and
speculations. How can I show you Zen unless you first empty your cup?" '
From: David Hanley
Subject: Re: Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <38E37F71.41B3AB75@ncgr.org>
William Deakin wrote:
> I spent 2-years (in the not so distant past) working on a vt100 (24x80)
> with vi and it then becomes very very clear the importance of cutting
> down on the visual clutter, number of lines in code blocks and
> indentation styles. I challenge anybody who has a similar experiences to
> say smart things like `why don't you reduce the font 25%' or `the number
> of extra lines caused by dopey formatting isn't important.'
Well, I won't say that, but in that kind of environment, the added ease of
editing added by shorter lines helps me more than the extra scrolling
hurts me. But maybe that makes me a hacker(?)
dave
From: Will Deakin
Subject: Re: Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <8c0h7u$kvl$1@epos.tesco.net>
David Hanley:
>Well, I won't say that, but in that kind of environment, the added ease of
>editing added by shorter lines helps me more than the extra scrolling
>hurts me.
Possibly but consider these questions: Did you work like this for an extended
period? did your keyboard have arrow keys? did you have a 140-odd line resource
script? Were you working on a legacy with 1.5M lines of code[1].
>But maybe that makes me a hacker(?)
Maybe it does. But does that mean I'm not?
;) will
[1] No, this was not lisp. I have never been paid a lira for lisp coding. Well,
not more that a for a couple of days work anyway. (I also realise this is
heading into Monty Python `Yorkshire Tyke' territory so please ignore this.)
William Deakin wrote:
> `Nan-in received a university professor who came to inquire about
> enlightenment.
>
> Nan-in served tea. He poured his visitor's cup full, and then kept on
> pouring.
>
> The professor watched the overflow until he could not restrain himself.
> "Stop! No more will go in!"
>
> "Like this cup", Nan-in said, "you are full of your own opinions and
> speculations. How can I show you Zen unless you first empty your cup?" '
I've known many university professors whose lecturing style
was very much like Nan-in's tea-pouring style. :-)
--
Gareth McCaughan ················@pobox.com
sig under construction
From: Fernando D. Mato Mira
Subject: Outlining (was: Dangling Closing Parentheses vs. Stacked Closing Parentheses)
Date:
Message-ID: <38E393FF.A07145F4@acm.org>
Tim Bradshaw wrote:
> * Anthony Cartmell wrote:
>
> > Try a font 25% smaller?
>
> There is *no* screen that is big enough. That's the point.
Now, how do I do outlining in ILISP? Although otherwise primitive,
the Transputer Development System had that great way of editing
Occam programs. There's some outline mode in XEmacs, but
it's not for Lisp.
--
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
From: Hannu Koivisto
Subject: Re: Outlining (was: Dangling Closing Parentheses vs. Stacked Closing Parentheses)
Date:
Message-ID: <87d7ocz1rg.fsf@senstation.vvf.fi>
"Fernando D. Mato Mira" <········@acm.org> writes:
| Occam programs. There's some outline mode in XEmacs, but
| it's not for Lisp.
Hmm? Both outline (M-x outline-minor-mode) and hideshow (M-x
hs-minor-mode) packages work with Lisp. Perhaps there are other
packages (that possibly don't work with Lisp) but I'd suggest you
try outline.
--
Hannu
and silence that speaks so much louder than words
From: Fernando D. Mato Mira
Subject: Re: Outlining (was: Dangling Closing Parentheses vs. Stacked Closing Parentheses)
Date:
Message-ID: <38E47273.C3782F8B@acm.org>
Hannu Koivisto wrote:
> "Fernando D. Mato Mira" <········@acm.org> writes:
>
> | Occam programs. There's some outline mode in XEmacs, but
> | it's not for Lisp.
>
> Hmm? Both outline (M-x outline-minor-mode) and hideshow (M-x
> hs-minor-mode) packages work with Lisp. Perhaps there are other
> packages (that possibly don't work with Lisp) but I'd suggest you
> try outline.
Outline seems to be working always globally, and get confused about
what the "next at same level" and things like that are.
Hideshow is OK, but it only knows how to hide/show blocks, and not the
exact opposite,
for example, ie, hide the bindings but show the body of a FLET.
Thanks,
--
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
"Fernando D. Mato Mira" <········@acm.org> writes:
> Hideshow is OK, but it only knows how to hide/show blocks, and not the
> exact opposite, for example, ie, hide the bindings but show the body
> of a FLET.
dunno if this is really "opposite", but have you tried placing the
cursor at 1 when doing a hide?
2 1
(flet ((func-a (args) (mangle args))
(func-b (args) (unmangle args)))
(func-a (func-b some-data)))
you may also find it useful to do `hs-hide-level' at 2.
thi
From: Marco Antoniotti
Subject: Re: Outlining (was: Dangling Closing Parentheses vs. Stacked Closing Parentheses)
Date:
Message-ID: <lwwvmj388v.fsf@parades.rm.cnr.it>
"Fernando D. Mato Mira" <········@acm.org> writes:
> Tim Bradshaw wrote:
>
> > * Anthony Cartmell wrote:
> >
> > > Try a font 25% smaller?
> >
> > There is *no* screen that is big enough. That's the point.
>
> Now, how do I do outlining in ILISP? Although otherwise primitive,
> the Transputer Development System had that great way of editing
> Occam programs. There's some outline mode in XEmacs, but
> it's not for Lisp.
You don't. ILISP is not about "editing" lisp code. It is about
interacting with a (mostly Common) Lisp environment. :)
I suppose some "outline" hacking would fit the bill. Although you'd
miss some paren balancing features.
"The right thing" to do would be to write a fancy ELisp package
capable of doing S-expr collapsing. This beast cannot be line based:
Lisp ain't Occam or Python.
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
From: Tom Breton
Subject: Re: Outlining (was: Dangling Closing Parentheses vs. Stacked Closing Parentheses)
Date:
Message-ID: <m3wvmjoswn.fsf@world.std.com>
Marco Antoniotti <·······@parades.rm.cnr.it> writes:
> I suppose some "outline" hacking would fit the bill. Although you'd
> miss some paren balancing features.
>
> "The right thing" to do would be to write a fancy ELisp package
> capable of doing S-expr collapsing. This beast cannot be line based:
> Lisp ain't Occam or Python.
Then ttn has already done the rite thing. Guys, hideshow mode (M-x
hs-minor-mode) already does all that's been mentioned.
--
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
From: Marco Antoniotti
Subject: Re: Outlining (was: Dangling Closing Parentheses vs. Stacked Closing Parentheses)
Date:
Message-ID: <lw1z4p4ydl.fsf@parades.rm.cnr.it>
Tom Breton <···@world.std.com> writes:
> Marco Antoniotti <·······@parades.rm.cnr.it> writes:
>
> > I suppose some "outline" hacking would fit the bill. Although you'd
> > miss some paren balancing features.
> >
> > "The right thing" to do would be to write a fancy ELisp package
> > capable of doing S-expr collapsing. This beast cannot be line based:
> > Lisp ain't Occam or Python.
>
> Then ttn has already done the rite thing. Guys, hideshow mode (M-x
> hs-minor-mode) already does all that's been mentioned.
Cool. I was unaware of this.
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
From: Raymond Wiker
Subject: Re: Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <871z4solez.fsf@foobar.orion.no>
"Anthony Cartmell" <··········@csi.com> writes:
> "Christopher Browne" <········@news.hex.net> wrote in message
> ··························@news4.giganews.com...
> > Centuries ago, Nostradamus foresaw a time when David Hanley would say:
> > >"Fernando D. Mato Mira" wrote:
> > >> 3 code + 1 space. That's 25% wasted space in your "right version"
> > >> [20% if a _useful_ coment line is added on top of each]
> > >
> > >And? My hard drive is not going to get overfull because of this
> > >"wasted" space.
> >
> > Your *screen* will get overfull, and a 21" screen is considerably more
> > expensive than a 19" one, and bigger ones are more exorbitant still...
>
> Try a font 25% smaller?
*Some* of us actually want to read what's on the
screen. Anyways, however many lines/columns you can actually show (and
read!) at the same time, you *always* need more :-)
--
Raymond Wiker, Orion Systems AS
+47 370 61150
From: Fernando D. Mato Mira
Subject: Re: Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <38E33075.6876AC89@acm.org>
Raymond Wiker wrote:
> screen. Anyways, however many lines/columns you can actually show (and
> read!) at the same time, you *always* need more :-)
Like disk space ;)
[totally unrelated, I just couldn't help going full circle ;)]
--
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
From: Tim Bradshaw
Subject: Re: Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <ey3r9cs4msk.fsf@cley.com>
* Fernando D Mato Mira wrote:
> Raymond Wiker wrote:
>> screen. Anyways, however many lines/columns you can actually show (and
>> read!) at the same time, you *always* need more :-)
> Like disk space ;)
No, I think this is crucially different. In my experience, things
like disk space (and to some extent memory and cycles) are now *so*
cheap that is is basically easy to have more than you ever need for
many purposes. Of course, it depends on your purpose -- if you want
to accurately simulate atomic weapons or datamine geological data or
compile large C++ systems, run Word or some other similarly demanding
task then it probably is not true. But if you merely want to hack
Lisp it's now *easy* to have more than enough disk space, and probably
memory and cycles too.
But this is not true for screen area in a really bad way. I was using
Fujitsu Eagles 10 years ago (3xxMb, and a 2-person lift), and I'm now
using (obsolescent) 10-30 Gb disks which fit in the palm of my hand.
If we run out of disk space we just buy more, it's a trivial expense.
But 10 years ago I was using a screen which was 1152x900 (and has
access to screens which were 16xx x something) and now I'm using
1280x1024, which is an insignificant improvement (OK it's 24bit colour
rather than 2bit, but that's doesn't help text much).
--tim
From: David Hanley
Subject: Re: Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <38E11CE6.69C0ADA6@ncgr.org>
Without getting into a religous war, there are times when I use
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
On Tue, 28 Mar 2000 13:58:14 -0700, David Hanley <···@ncgr.org> wrote:
> (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?
What about the following?
(defstruct person
;; a string
name
;; the person's street address
address
;; the symbol 'male or 'female if known, nil of otherwise
gender)
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
From: David Hanley
Subject: Re: Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <38E26006.85E4971B@ncgr.org>
Paolo Amoroso wrote:
>
> What about the following?
>
> (defstruct person
> ;; a string
> name
> ;; the person's street address
> address
> ;; the symbol 'male or 'female if known, nil of otherwise
> gender)
I guess that works, but I'm not used to seeing comments that way.
Not wrong, however. Still has the quick-insertion issue, though.
dave
From: Robert Monfera
Subject: Re: Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <38EAF236.5D62382C@fisec.com>
David Hanley wrote:
> (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?
(defclass name ()
((first-name :type string)
(last-name :type string)
[...]))
[...]
(defclass person ()
((name :type name)
(address :type street-address)
(gender :type gender)))
Robert
From: Jim Bushnell
Subject: Re: Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <8bvv55$c5o$1@sloth.swcp.com>
Wow! At this writing there are 138 postings in this thread. There are a lot
of people wasting a lot of time on a relatively trivial matter.
Jim Bushnell
David J. Cooper <·······@genworks.com> wrote in message
······················@genworks.com...
> Hello,
>
> 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
> ·······@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
From: Will Deakin
Subject: Re: Dangling Closing Parentheses vs. Stacked Closing Parentheses
Date:
Message-ID: <8c0hcm$l0l$1@epos.tesco.net>
Jim Bushnell wrote:
>Wow! At this writing there are 138 postings in this thread. There are a lot
>of people wasting a lot of time on a relatively trivial matter.
Well thank you for making that 139!
Best Regards,
;) will