> | 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).
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 :(
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
> 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.
> (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.
> 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? :-)
> "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).
On Tue, 28 Mar 2000 13:58:14 -0700, David Hanley <d...@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)
* "Anthony Cartmell" <AJCartm...@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.
> (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.
> 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++.
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... cbbro...@ntlug.org- <http://www.ntlug.org/~cbbrowne/lsf.html>
* Tom Breton <t...@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.
> * "Anthony Cartmell" <AJCartm...@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.
> 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...
"Anthony Cartmell" <AJCartm...@csi.com> writes: > "Christopher Browne" <cbbro...@news.hex.net> wrote in message > news:OzxE4.42154$17.948927@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 :-)
Anthony Cartmell wrote: > "Fernando D. Mato Mira" <matom...@iname.com> wrote in message > news:38E1D09D.A3369087@iname.com... > > Anthony Cartmell wrote:
> > "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
