Indentation
Johan Kullstam
> Barry Margolin wrote:
>
> >> (defun num-list (a b &optional (d 1))
> >> (do ((x a (+ x d)) (li nil))
> >> ((> x b) (nreverse li)) (push x li)))
>
> > Are you *trying* to make life difficult for the people who are volunteering
> > assistance, by completely messing up the formatting of your functions?
>
> No, I'm very obliged for your help. I received in this list answers
> to questions, which often were very simple for the experts, but for which
> I could find no solution in the books.
>
> The problem of indentation is interesting for me, because most
> programmers stick to it as if it were an axiom. I had a similar
> discussion several years ago about C, and I was not able to
> convince anybody. I have two arguments, however:
>
> (1) Writing a program should be similar as far as possbile to
> writing a letter. Also in letters some structure is useful,
> but it should be esthetic and functional, not ritual.
> This applies also to C and most other languages.
you seem to be unique in this aspect.
i think most people here dislike counting parentheses. i ignore
parens and assume that the indentation will give cues as to what is
wrapped up in which s-exp. imo parens are for compilers. indentation
is for humans. your experience seems different. i am puzzled, but
hey, if it works for you...
> (2) More specifically in Lisp I try to memorize (and to teach to
> memorize) the shapes which can appear. For example:
> "A do has the following structure ... Therefore, when you
> see a do, look first at the assignments, then at the
> break-condition and the result, then at the single instructions."
> And so on. In my opinion this is a good training, and after
> little time one has no more need to study the indentations,
> which also takes time and distracts.
i like indentation since my brain remembers spacial patterns fairly
well as compared to counting parens.
> Of course, when I write on the computer (I'm using Emacs, but always
> only in fundamental mode), I verify the balance of parentheses with
> the editor. But I find it useful to write simple functions first by
> hand and to control by myself the parentheses. I don't find it
> difficult. With this training the )))))))))))))))-boing disappears
> quickly.
i assume you have tried the lisp modes. a good lisp mode makes
maintaining indentation easy.
> It was on this list (or perhaps in a paper of Kent Pitman) where I read
> some days ago that in computer science sometimes first habits become
> sanctified. In part this may be true also for indentation. Perhaps, but
> this is a personal argument, it is also a question of eyes. For me it
> takes more time to control the indentation (with more rows to read) than
> to examine the structure.
> With no intention of flame.
and no intent of flamage from me either.
--
J o h a n K u l l s t a m
[kull...@ne.mediaone.net]
Don't Fear the Penguin!
thi
> The problem of indentation is interesting for me, because most
so you make it a problem for other people too?
thi
Josef Eschgfaeller
Barry Margolin wrote:
>> (defun num-list (a b &optional (d 1))
>> (do ((x a (+ x d)) (li nil))
>> ((> x b) (nreverse li)) (push x li)))
> Are you *trying* to make life difficult for the people who are volunteering
> assistance, by completely messing up the formatting of your functions?
No, I'm very obliged for your help. I received in this list answers
to questions, which often were very simple for the experts, but for which
I could find no solution in the books.
The problem of indentation is interesting for me, because most
programmers stick to it as if it were an axiom. I had a similar
discussion several years ago about C, and I was not able to
convince anybody. I have two arguments, however:
(1) Writing a program should be similar as far as possbile to
writing a letter. Also in letters some structure is useful,
but it should be esthetic and functional, not ritual.
This applies also to C and most other languages.
(2) More specifically in Lisp I try to memorize (and to teach to
memorize) the shapes which can appear. For example:
"A do has the following structure ... Therefore, when you
see a do, look first at the assignments, then at the
break-condition and the result, then at the single instructions."
And so on. In my opinion this is a good training, and after
little time one has no more need to study the indentations,
which also takes time and distracts.
Of course, when I write on the computer (I'm using Emacs, but always
only in fundamental mode), I verify the balance of parentheses with
the editor. But I find it useful to write simple functions first by
hand and to control by myself the parentheses. I don't find it
difficult. With this training the )))))))))))))))-boing disappears
quickly.
It was on this list (or perhaps in a paper of Kent Pitman) where I read
some days ago that in computer science sometimes first habits become
sanctified. In part this may be true also for indentation. Perhaps, but
this is a personal argument, it is also a question of eyes. For me it
takes more time to control the indentation (with more rows to read) than
to examine the structure.
With no intention of flame.
J. Eschgfaeller
R. Matthew Emerson
> (2) More specifically in Lisp I try to memorize (and to teach to
> memorize) the shapes which can appear. For example:
Exactly. Correct indentation enables one to easily see the
charateristic shapes of expressions.
> Of course, when I write on the computer (I'm using Emacs, but always
> only in fundamental mode)
Why do you decline to use the power of your tools? Emacs will indent
your code correctly for you.
> It was on this list (or perhaps in a paper of Kent Pitman) where I read
> some days ago that in computer science sometimes first habits become
> sanctified. In part this may be true also for indentation. Perhaps, but
> this is a personal argument, it is also a question of eyes. For me it
> takes more time to control the indentation (with more rows to read) than
> to examine the structure.
If you want others to be able to read your code, you have to conform
to the standard indenting conventions. Debate is pointless. You will
lose big if you refuse to indent your code in the canonical way.
-matt
Vassil Nikolov
Josef Eschgfaeller wrote:
[...]
> (1) Writing a program should be similar as far as possbile to
> writing a letter.
Why?
A letter carries a message; a program carries instructions.
The purpose is quite different. Also, a letter is intended for
a human being only; a program is intended for a machine (which
does not care about indentation), but should also be readable
by human beings, including ones who did not write it.
I don't think that writing a program is very similar to writing
a letter, or to writing a poem, or a short story, or whatever.
The nearest natural-language match I can think of off the top
of my head is instructions how to perform operations in a
user or maintenance manual or some such. One usually finds
nested (numbered and bulleted) lists in such manuals that
are indented at appropriate levels and that would be very
difficult to read without indentation.
[...]
> (2) More specifically in Lisp I try to memorize (and to teach to
> memorize) the shapes which can appear.
What do you mean by `shapes'? Since you don't use indentation,
it can't be the `silhouette' of the program text that is produced
by indentation.
> For example:
> "A do has the following structure ... Therefore, when you
> see a do, look first at the assignments, then at the
> break-condition and the result, then at the single instructions."
> And so on. In my opinion this is a good training, and after
> little time one has no more need to study the indentations,
> which also takes time and distracts.
Maybe if the DO does not contain nested control constructs, one
could still manage without indentation (though I am not sure).
However, what if there is a DO within a DO? Wouldn't it take
time to disentangle one from the other?
>
> Of course, when I write on the computer (I'm using Emacs, but always
> only in fundamental mode), I verify the balance of parentheses with
> the editor. But I find it useful to write simple functions first by
> hand and to control by myself the parentheses. I don't find it
> difficult. With this training the )))))))))))))))-boing disappears
> quickly.
[...]
Indentation is not a means for _verifying_ the balance of parentheses.
(In fact, with properly indented code one could pay little attention to
those parentheses that are the first or last non-white-space characters
on a line.) Indentation is a means for making the structure of code
_apparent_ to a human reader. I stress apparent, because this structure
does not go away in the absence of indentation, but (except the trivial
cases) requires significant cognitive effort (on part of the human
reader) to discover if the assistance provided by indentation is not
there.
(Of course, there is something worse than lack of indentation, and
that is wrong indentation, but that's another topic.)
Vassil Nikolov
Permanent forwarding e-mail: vnik...@poboxes.com
For more: http://www.poboxes.com/vnikolov
Abaci lignei --- programmatici ferrei.
Marco Antoniotti
Josef Eschgfaeller <e...@felix.unife.it> writes:
> Barry Margolin wrote:
>
> >> (defun num-list (a b &optional (d 1))
> >> (do ((x a (+ x d)) (li nil))
> >> ((> x b) (nreverse li)) (push x li)))
>
> > Are you *trying* to make life difficult for the people who are volunteering
> > assistance, by completely messing up the formatting of your functions?
>
> No, I'm very obliged for your help. I received in this list answers
> to questions, which often were very simple for the experts, but for which
> I could find no solution in the books.
>
> The problem of indentation is interesting for me, because most
> programmers stick to it as if it were an axiom. I had a similar
> discussion several years ago about C, and I was not able to
> convince anybody. I have two arguments, however:
>
> (1) Writing a program should be similar as far as possbile to
> writing a letter. Also in letters some structure is useful,
> but it should be esthetic and functional, not ritual.
> This applies also to C and most other languages.
>
> (2) More specifically in Lisp I try to memorize (and to teach to
> memorize) the shapes which can appear. For example:
> "A do has the following structure ... Therefore, when you
> see a do, look first at the assignments, then at the
> break-condition and the result, then at the single instructions."
> And so on. In my opinion this is a good training, and after
> little time one has no more need to study the indentations,
> which also takes time and distracts.
>
> Of course, when I write on the computer (I'm using Emacs, but always
> only in fundamental mode),
^^^^^^^^^^^
Continuiamo cosi`, facciamoci del male!
Since you know Italian, you can appreciate the citation :)
Cheer
--
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
Andy Freeman
Josef Eschgfaeller <e...@felix.unife.it> wrote:
> The problem of indentation is interesting for me, because most
> programmers stick to it as if it were an axiom. I had a similar
> discussion several years ago about C, and I was not able to
> convince anybody. I have two arguments, however:
>
> (1) Writing a program should be similar as far as possbile to
> writing a letter.
Why? And, if so, why is the SAME formatting appropriate? (Text
structure doesn't have the same kind of syntactic clues that most
programming languages do.)
> Also in letters some structure is useful,
> but it should be esthetic and functional, not ritual.
What is the function of filled lines for computer programs?
> (2) More specifically in Lisp I try to memorize (and to teach to
> memorize) the shapes which can appear. For example:
> "A do has the following structure ... Therefore, when you
> see a do, look first at the assignments, then at the
> break-condition and the result, then at the single instructions."
> And so on. In my opinion this is a good training,
Since there isn't a "shape" in filled lines, there's no pattern
for people to see. They have to inspect and reconstruct the structure.
Good indentation reveals structure without requiring inspection
and reconstruction of that structure from constituents. Indentation
is an outline - you can see what's going on at any level of detail
without inspecting deeper levels of detail. (When formatting
reflects structure, I don't have to know much about a specific
form to understand the program as a whole and that form's place
and role in that program.)
BTW - What's the largest program you've ever understood or written
that someone else has been able to easily understand? For some
people who read comp.lang.lisp, the answer is hundreds of thousands
of lines....
> little time one has no more need to study the indentations,
> which also takes time and distracts.
Takes time from what? Distracts from what?
A huge part of my brain is wired for visual pattern matching.
Formatting that takes advantage of that wiring lets me understand
a program without reading each and every character. It's like
speed reading - visual chunking works. (For what it's worth,
I do much of my composition, for both text and program, "off line".)
> It was on this list (or perhaps in a paper of Kent Pitman) where I
read
> some days ago that in computer science sometimes first habits become
> sanctified.
They laughed at Newton, they laughed at Einstein (actually
"they" didn't), but they also laughed at Bozo the Clown.
> this is a personal argument, it is also a question of eyes. For me it
> takes more time to control the indentation (with more rows to read)
than
> to examine the structure.
It's like sheet music. You don't read the rows, you don't read the
characters, you "read" the picture, just as you don't count the
staff lines - you "read" the structure.
-andy
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
Tim Bradshaw
> (1) Writing a program should be similar as far as possbile to
> writing a letter. Also in letters some structure is useful,
> but it should be esthetic and functional, not ritual.
> This applies also to C and most other languages.
Yes, it is similar to writing a letter, in particular one of the
purposes is that the people to whom you are writing should be able to
read what you have written. Since the great majority of Lisp people
rely on the standard indentation style -- which we consider `aesthetic
& functional, not ritual' -- to read Lisp code, then you should as
well, at least when you want anyone else to read your programs.
--tim
Josef Eschgfaeller
comp.lang.lisp wrote:
>> The problem of indentation is interesting for me
> so you make it a problem for other people too?
No, I didn't mean it in this negative or aggressive way. This problem
belongs to the more general communication problem with mathematical
or technical writing. Often habits of the insiders there are not
obvious or easy for the general public. So I wanted to say that
indeed I am concerned with these aspects and if I write in a certain
way, I think about it, too.
A side-interest in this is also, to what extent behind such flames
are technical reasons, what is pure habit and how much is it the
immune system which becomes active (eliminate everything you don't
know)? It is strange, but perhaps related, that typically in such
discussion lists there are never girls. My classes consist mainly
of female students, and they are as good in programming as the males
and, as it seems, especially attracted by the linguistic aspects
of Lisp.
This doesn't mean that I cannot be wrong or that I should not
adapt my codes, when posted to the list, to the general use.
This is no problem. I did not want a long discussion, if the
question is not interesting or if everybody has a firm conviction.
> a program ... should also be readable by human beings, including
> ones who did not write it.
Agree fully. But one can learn different styles.
> What do you mean by `shapes'?
Something as the interior or logical shape. I meant approximately
that when you have ready such a shape, you can put in easily the
constructions in your program. In some sense indentation means that
you never make that effort and so you are compelled each time to
begin from new.
Often such crutches, when not more necessary, should be thrown away.
This happens very often in natural language learning. It's a general
consideration, maybe in the concrete case I'm wrong.
> However, what if there is a DO within a DO? Wouldn't it take
> time to disentangle one from the other?
Perhaps it could also be a reason to avoid or reorganize too
complicated structures.
> with properly indented code one could pay little attention to
> those parentheses
I'm looking now at some pieces of code in Graham's books. In fact,
I can see some structures immediately, but it appears to me that
the more I look at it, the more it resembles normal C code.
I lose the Lisp a little.
Mathematically it is the old problem of how to represent a tree
by a string. There are many ways, among them indentation, but I
don't know one perfectly corresponding to the human brain.
> Since there isn't a "shape" in filled lines, there's no pattern
> for people to see. They have to inspect and reconstruct the structure.
The danger is, as in natural language, that one does not more
read with attention what is written. People who are accustomed to
read much, usually can understand easily texts of considerable
complexity.
> BTW - What's the largest program you've ever understood or written
> that someone else has been able to easily understand? For some
> people who read comp.lang.lisp, the answer is hundreds of thousands
> of lines....
In fact, I'm impressed by the competence of the members of this
list. It's truly not the first one I participate. Lisp is a rich and
deep language and I have still much to learn.
Josef Eschgfaeller
Dipartimento Matematico
Universita' di Ferrara
e...@felix.unife.it e-mail
http://felix.unife.it/ home page
Gareth McCaughan
> (1) Writing a program should be similar as far as possbile to
> writing a letter. Also in letters some structure is useful,
> but it should be esthetic and functional, not ritual.
> This applies also to C and most other languages.
Most ordinary natural-language text doesn't have anything like
as much complicated structure as a non-trivial computer program
(in particular, deeply nested structures are rare), and when
there is complicated syntactic structure there are usually
special "noise words" that clarify it. In Lisp, all the structure
is conveyed by parentheses, and most of us don't like to have to
count parentheses.
Reading a Lisp or C program (I suspect that wordier languages like
Pascal, Modula-3 and COBOL cope better) without indentation isn't
like reading an ordinary English sentence without indentation. It's
more like reading a string of the sort of contorted sentences that
one can find in popular books on linguistics ("oysters oysters oysters
split split split") or parodies of the German language (with a string
of 6 verbs at the end -- my brain refuses to construct an example
right now).
> (2) More specifically in Lisp I try to memorize (and to teach to
> memorize) the shapes which can appear. For example:
> "A do has the following structure ... Therefore, when you
> see a do, look first at the assignments, then at the
> break-condition and the result, then at the single instructions."
A good thing to do. And it's made easier by sensible indentation
conventions, which let you understand even quite complicated
DO forms without having to count parentheses.
*
Oh, you wanted to know about the oysters? Well, you could rewrite
it as "those oysters whom those oysters whom oysters split, split,
are splittable". Still confused? Try it with some indentation.
Those oysters whom
those oysters whom
those oysters whom oysters split
split
are splittable.
At this point it becomes (marginally) comprehensible, at least for me.
The structure of the sentence is exactly parallel to the much easier
"The game those boys I met invented resembles chess".
[ oysters oysters oysters split split split ]
--
Gareth McCaughan Dept. of Pure Mathematics & Math. Statistics,
Gareth.M...@pobox.com Cambridge University, England.
Pierre R. Mai
> The problem of indentation is interesting for me, because most
> programmers stick to it as if it were an axiom. I had a similar
It is not an axiom, but a convention. (There are similarities between
the two, but also differences).
> discussion several years ago about C, and I was not able to
> convince anybody. I have two arguments, however:
The case for indentation of C (and many other languages) is weakened
by the fact that there is no canonical way to indent C, and there have
been many flame wars about the right way to indent it. That, IMHO,
totally misses the point. Like with Lisp's choice for the list as the
canonical structure to represent source code, the important thing is
not finding _the_ right absolute best way to do it (there probably is
none, because of different trade-offs), but to get agreement on one
good way, and stick to it.
> (1) Writing a program should be similar as far as possbile to
> writing a letter. Also in letters some structure is useful,
This is just a conjecture. Why do you feel that writing a program
should be like writing a letter? Why not like writing a novel? Or a
poem? Or indeed like writing a mathematical proof? Maybe some program
writing is like writing limericks, and some like writing inventory
lists? Maybe KMP writes code like philosophical arguments, RMS like
manifestos, and PRM in a caffeine-induced stream of consciousness? (No
insults intended ;).
If you want this to be an argument, you would have to go into some
detail why
> but it should be esthetic and functional, not ritual.
> This applies also to C and most other languages.
I don't like sentences that go "C and most other languages". I don't
think that C is a very good canonical example to pick for "most other
languages". C is a very good canonical example for C and most other
C-like languages (at the syntax level, which we are probably most
concerned with, when we talk about indentation, which has to mix with
syntax). It isn't even a good example for most Algol-like languages.
> (2) More specifically in Lisp I try to memorize (and to teach to
> memorize) the shapes which can appear. For example:
As others have commented before, it is exactly these shapes that
indentation in Lisp is intended to convey, using our powers of
spacial recognition.
> "A do has the following structure ... Therefore, when you
> see a do, look first at the assignments, then at the
> break-condition and the result, then at the single
> instructions."
And it benefits you greatly, when those parts are always at the same
positions relative to another.
> And so on. In my opinion this is a good training, and after
> little time one has no more need to study the indentations,
> which also takes time and distracts.
One doesn't "study the indentation". If you have to study it, then
indentation isn't helpful. Indentation has the same role as white-space
in printing: If it doesn't guide you instinctively, it's either done
wrong, or you aren't used to it. Take for example the convention of
indenting the first line of paragraphs in texts: You don't study that
indentation, but at once it's clear that this is another paragraph.
Of course in other cultures, there are other conventions, and you have
to get used to them, prior to reaping the benefits.
> Of course, when I write on the computer (I'm using Emacs, but always
> only in fundamental mode), I verify the balance of parentheses with
> the editor. But I find it useful to write simple functions first by
> hand and to control by myself the parentheses. I don't find it
> difficult. With this training the )))))))))))))))-boing disappears
> quickly.
Hmmm, when I write functions by hand, I mostly don't care about the
parentheses, but only try to get the indentation right for two
reasons: The parentheses are for the computer, which can't read my
writing anyway, and I can't be bothered to keep the parentheses count
balanced without the help of Emacs.
> It was on this list (or perhaps in a paper of Kent Pitman) where I read
> some days ago that in computer science sometimes first habits become
> sanctified. In part this may be true also for indentation. Perhaps, but
That is of course a correct observation, and there are indeed
indications that indentation not only came into CS because of
historical/technical reasons, but that many people care so deeply
about indentation because it is still in some way connected to
well-formedness. There is also precedent in mathematics for
indentation (and other syntactical) conventions.
And Dijkstra observed[1]:
I would like to point out that, in very much the same way,
mathematics has suffered and still suffers from the tryanny of
"the average mathematician". Improvements in notation, in
language or concepts, are rejected because such deviations
from the hallowed tradition would only confuse the average
mathematician ...
However, there is also ample evidence that suggests that spacial
placement is a very powerful tool for the presentation of information
in a way that aids the process of habitually finding the information
you want. That is one of the (IMHO sadly under-exercized) foundations
of GUIs.
So it seems to me that there would be quite a bit further research and
experimentation necessary to show that letting go of the conventional
way of indenting (especially in Lisp, where there is a canonical way),
would give us any benefits. That is meant by sanctified: Holding
onto something, in the face of existing evidence to the contrary. I
can't see the evidence that indentation is bad, so I might as well
hold on to the convention.
> this is a personal argument, it is also a question of eyes. For me it
> takes more time to control the indentation (with more rows to read) than
> to examine the structure.
But why do you control the indentation, instead of letting it guide
you? Do you control the indentation and layout in printed matters as
well?
If you really want to cling on to your indentation style, I'd suggest
running your souce through the lisp pretty printer prior to posting
it, so that the rest of the community can read it. Otherwise code
tends to be overlooked, which sometimes obscures the problem...
> With no intention of flame.
Likewise...
Regs, Pierre.
Footnotes:
[1] Dijkstra, Edsger W.: "On the Economy of doing Mathematics", In:
"Mathematics of Program Construction", Springer LNCS 669, 1992.
--
Pierre Mai <pm...@acm.org> PGP and GPG keys at your nearest Keyserver
"One smaller motivation which, in part, stems from altruism is Microsoft-
bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
Andy Freeman
Josef Eschgfaeller <e...@felix.unife.it> wrote:
> > ones who did not write it.
>
> Agree fully. But one can learn different styles.
People who share a convention can communicate more easily. What
advantages of your convention make it worth the communities'
effort to learn it? Why should a newcomer learn your style?
(It really doesn't matter which side of the road people drive
on, but it's "efficient" for them to agree.)
> > What do you mean by `shapes'?
>
> Something as the interior or logical shape. I meant approximately
> that when you have ready such a shape, you can put in easily the
> constructions in your program. In some sense indentation means that
> you never make that effort and so you are compelled each time to
> begin from new.
Huh? The shape formed by indentation tells me lots of things,
so I never "begin from new".
We haven't seen any examples of something valuable revealed by
the "like text" style of program formatting. All we've seen is
program structure obscured by that style.
> Perhaps it could also be a reason to avoid or reorganize too
> complicated structures.
"too complicated" is problem-specific. If a formatting scheme
can't clearly express the "best" way to solve the problem at
hand, the formatting scheme is an obstacle.
> > with properly indented code one could pay little attention to
> > those parentheses
>
> I'm looking now at some pieces of code in Graham's books. In fact,
> I can see some structures immediately, but it appears to me that
> the more I look at it, the more it resembles normal C code.
Since both languages have composition and sequencing, some structural
similarities are to be expected.
> The danger is, as in natural language, that one does not more
> read with attention what is written. People who are accustomed to
> read much, usually can understand easily texts of considerable
> complexity.
Text which is intentionally deceptive is always hard to understand.
However, programmers often make an effort to be easy to understand.
Most program text is read far more times than it is written, so helping
the reader is "efficient". (One nice thing about indentation is that
indenting programs can reveal many deceptions, hence the suggestion
about letting emacs reformat something as a quick check to see of
one's understanding.) Indentation is efficient for the things it
reveals, leaving more time for the "rest of the problem".
> > BTW - What's the largest program you've ever understood or written
> > that someone else has been able to easily understand? For some
> > people who read comp.lang.lisp, the answer is hundreds of thousands
> > of lines....
>
> In fact, I'm impressed by the competence of the members of this
> list.
I was obscure. Yes, some of the folks participating are incredibly
competent and thoughtful. However, my point is that some things
which "work" with small programs don't work with large ones, and
the distinction isn't necessarily obvious unless you have the
relevant experience.
You learn a lot by writing a 10k line program, and even more by
coming back to it 10 years later to make minor changes. Cranking
out lots of code that must be correct in a short amount of time
is also a learning experience. You won't expect these lessons
if you just do 1k one-timers. (The difference between 10k and
100k is also interesting.)
Barry Margolin
Josef Eschgfaeller <e...@felix.unife.it> wrote:
> memorize) the shapes which can appear. For example:
> see a do, look first at the assignments, then at the
> break-condition and the result, then at the single instructions."
> little time one has no more need to study the indentations,
> which also takes time and distracts.
But how can you easily tell where the assignments end and the
break-condition begins if it's not properly indented?
>>> (defun num-list (a b &optional (d 1))
>>> (do ((x a (+ x d)) (li nil))
>>> ((> x b) (nreverse li)) (push x li)))
When I look at the above code, I can't easily tell if it's iterating one
variable or two. It would be much easier if the DO form began with:
(do ((x a (+ x d))
(li nil))
((> x b) (nreverse li))
(push x li))
Now it's obvious that the X and LI clauses are at the same level, the (> x
b) is the end test, and that the PUSH form is in the body, not part of the
results section.
--
Barry Margolin, bar...@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Gareth McCaughan
[Josef Eschgfaeller wrote:]
>>>> (defun num-list (a b &optional (d 1))
>>>> (do ((x a (+ x d)) (li nil))
>>>> ((> x b) (nreverse li)) (push x li)))
>
> When I look at the above code, I can't easily tell if it's iterating one
> variable or two.
I think that particular example is pretty clear, simply because
it's so short and structurally simple. But I wonder what Josef
would make of something like this:
(defun knapsack0 (annotated-set bound min trunc) (when (or (null
annotated-set) (<= bound trunc)) (return-from knapsack0 (values nil
0))) (let* ((first-item (car annotated-set)) (remaining-set (cdr
annotated-set)) (item (car first-item)) (remainder (cdr first-item)))
(cond ((> item bound) (knapsack0 remaining-set bound min trunc)) ((<
remainder min) (multiple-value-bind (subset subset-sum) (knapsack0
remaining-set (- bound item) (- min item) trunc) (values (cons item
subset) (+ item subset-sum)))) (t (multiple-value-bind (subset0
subset-sum-0) (knapsack0 remaining-set bound min trunc) (multiple-value-bind
(subset1 subset-sum-1) (knapsack0 remaining-set (- bound item) (- (max
min subset-sum-0) item) trunc) (if (> (+ item subset-sum-1) subset-sum-0)
(values (cons item subset1) (+ item subset-sum-1)) (values subset0
subset-sum-0))))))))
It's certainly not *impossible* to read this without any
indentation. But it's pretty unpleasant. Here's a quick
test.
- What is the role of ITEM in line 4? Function being called,
variable being bound, or something else?
- What is being done with the result of the VALUES form
that begins on line 7? Under what circumstances?
I'm sure Josef can answer them. But I bet he can't answer them
as quickly as he could with the indented code to look at.
And that's rather simple code; it doesn't, for instance,
contain any instance of DO, or anything complicated inside
the bindings of a LET.
Mark K. Gardner
[Good material not needed for my question removed...]
>way of indenting (especially in Lisp, where there is a canonical way),
I have been following the discussion waiting for someone to give a
reference to something which gives the canonical way to indent Lisp
code. (Yes, I rely on Emacs to format things on correctly when I can
run Emacs but would like to know what the rules are so that I can
maintain the proper indention when I can't run Emacs.) Would you
please post a reference to the canonical way?
Mark
--
Mark K. Gardner (mkga...@cs.uiuc.edu)
University of Illinois at Urbana-Champaign
Real-Time Systems Laboratory
--
Paolo Amoroso
wrote:
> I don't think that writing a program is very similar to writing
> a letter, or to writing a poem, or a short story, or whatever.
Incidentally, organizing and writing source code as part of a larger prose
text documenting the system is the main idea behind Knuth's "literate
programming".
Paolo
--
Paolo Amoroso <amo...@mclink.it>
Paolo Amoroso
wrote:
> A side-interest in this is also, to what extent behind such flames
> are technical reasons, what is pure habit and how much is it the
> immune system which becomes active (eliminate everything you don't
> know)? It is strange, but perhaps related, that typically in such
I seem to have read that the first Lisp books, published around the
sixties, used a style similar to yours for code samples--i.e. without
indentation. Maybe someone in this group can explain why this changed in
later decades.
One possible technical reason may be that, since Lisp uses a prefix syntax,
it's easier to identify operators by means of the characteristic patterns
that proper indentation makes apparent. Those operators are quick clues to
the main constructs such as function calls, definitions, binding forms,
etc. But when the code is laid out as a mostly continuous stream of text,
such clues may appear anywhere and it's harder to locate them.
The technical importance of indentation is also suggested by the inclusion
of extensive pretty-printing facilities in ANSI Common Lisp. The ANSI
standardization effort was probably driven more by pragmatic concerns than
ideological issues.
> discussion lists there are never girls. My classes consist mainly
> of female students, and they are as good in programming as the males
> and, as it seems, especially attracted by the linguistic aspects
> of Lisp.
Do you mean that your classes in Ferrara are attended by lots of girls who
appreciate Lisp? If so, sign me for your next class :)
> > However, what if there is a DO within a DO? Wouldn't it take
> > time to disentangle one from the other?
>
> Perhaps it could also be a reason to avoid or reorganize too
> complicated structures.
Most Lisp editors, the best known of which is Emacs (in Lisp--not
Fundamental--mode), are able to automatically indent this and other complex
constructs with a single keystroke.
> In fact, I'm impressed by the competence of the members of this
> list. It's truly not the first one I participate. Lisp is a rich and
> deep language and I have still much to learn.
Have you had a look at the wonderful paper "The Evolution of Lisp" by
Richard Gabriel and Guy Steele? It's available at:
ftp://ftp.cs.umbc.edu/pub/Memoization/Misc/Evolution-of-Lisp.ps.Z
Section 5 (Why Lisp is Diverse) lists a number of reasons why there's
something special or different about Lisp. One of the reasons is its
people.
Paolo Amoroso
wrote:
> The problem of indentation is interesting for me, because most
> programmers stick to it as if it were an axiom. I had a similar
I personally never accepted the--mostly standardized--Lisp indentation as
an axiom. I don't know how my brain is set up, but it's the only way I can
comfortably understand code fragments longer than a couple of lines. I need
both easily identifiable reference points and appropriate whitespace.
That's what proper indentation provides.
> Of course, when I write on the computer (I'm using Emacs, but always
> only in fundamental mode), I verify the balance of parentheses with
Just out of curiosity, why don't you use Lisp mode? It makes indentation a
non-issue.
> the editor. But I find it useful to write simple functions first by
> hand and to control by myself the parentheses. I don't find it
> difficult. With this training the )))))))))))))))-boing disappears
When I write Lisp code by hand, I use the right hand to write, and often
the left index-finger to point at the parenthesis I'm closing. I've heard
that others keep proper indentation but don't write all parentheses.
Paolo Amoroso
<mar...@copernico.parades.rm.cnr.it> wrote:
> Josef Eschgfaeller <e...@felix.unife.it> writes:
[...]
> > Of course, when I write on the computer (I'm using Emacs, but always
> > only in fundamental mode),
> ^^^^^^^^^^^
>
> Continuiamo cosi`, facciamoci del male!
>
> Since you know Italian, you can appreciate the citation :)
Here's an approximate translation as a (questionable :) service to those
who don't speak Italian: "let's go on, let's harm ourselves!".
Duane Rettig
Josef Eschgfaeller <e...@felix.unife.it> writes:
> comp.lang.lisp wrote:
>
> >> The problem of indentation is interesting for me
> > so you make it a problem for other people too?
>
> No, I didn't mean it in this negative or aggressive way. This problem
> belongs to the more general communication problem with mathematical
> or technical writing. Often habits of the insiders there are not
> obvious or easy for the general public. So I wanted to say that
> indeed I am concerned with these aspects and if I write in a certain
> way, I think about it, too.
I think that one of the non-obvious insider habits in this case is
the means by which we obtain the indentations we use. In all of your
posts, you give the impression to me that it is a chore to indent
lisp code, a hard exercise to be avoided. However, if you use
emacs/xemacs, vi (in lisp mode), internal lisp editors, or any
other editor that is lisp-indentation-friendly, the indentation
is usually automatic and almost unavoidable. And although all
of those choices give you slightly different indentations, all are
readable by those of us reading this newsgroup.
> This doesn't mean that I cannot be wrong or that I should not
> adapt my codes, when posted to the list, to the general use.
> This is no problem. I did not want a long discussion, if the
> question is not interesting or if everybody has a firm conviction.
It's not an issue of conviction; it's a question of communication.
If the sender of a message wants to communicate with a potential
receiver of the message, the sender must format it in a way that
can be understood by the receiver. And the quality of the
communication depends on the universality of the method of
communication. What you have been told by many on this list is that
the method you used to communicate your point was not easy to
receive. Thus, if you want more people to understand it, it must be
in a form that will more easily be received.
Incidentally, writing programs is also a form of communication in
several ways; when I write a program I am communicating to three
classes of receivers:
1. The computer.
2. Other programmers, who don't necessarily know my design.
3. Myself, six months after I wrote the program.
By far, the most challenging receiver to communicate with is #3.
> > a program ... should also be readable by human beings, including
> > ones who did not write it.
>
> Agree fully. But one can learn different styles.
There are any number of programs wich are lisp-friendly and which make
lisp programming very easy. And just as C has different styles (like
whether to put the opening-curly-brace in "if (x) { ..." immediately
after the test clause or on the next line), these editors usually
accomodate different lisp indentation styles. I don't think we would
object to different styles too much; what we objected to in the case
of the code you submitted was (pardon my being so blunt) no style at
all.
> > What do you mean by `shapes'?
>
> Something as the interior or logical shape. I meant approximately
> that when you have ready such a shape, you can put in easily the
> constructions in your program. In some sense indentation means that
> you never make that effort and so you are compelled each time to
> begin from new.
>
> Often such crutches, when not more necessary, should be thrown away.
> This happens very often in natural language learning. It's a general
> consideration, maybe in the concrete case I'm wrong.
A crutch is a device to aid a weak member of a system. Communication
is almost always the weakest member of any programming system.
Use crutches for communication as often as possible.
> > However, what if there is a DO within a DO? Wouldn't it take
> > time to disentangle one from the other?
>
> Perhaps it could also be a reason to avoid or reorganize too
> complicated structures.
You are welcome to keep your code as simple as you can make it
when you communicate it with us. However, how will you
communicate that code which you just can't simplify any more?
> > with properly indented code one could pay little attention to
> > those parentheses
>
> I'm looking now at some pieces of code in Graham's books. In fact,
> I can see some structures immediately, but it appears to me that
> the more I look at it, the more it resembles normal C code.
> I lose the Lisp a little.
Ahem, lisp is the older language here. Therefore, it is lisp
similarity that you see when you look at C code, not the other
way around.
:-)
> Mathematically it is the old problem of how to represent a tree
> by a string. There are many ways, among them indentation, but I
> don't know one perfectly corresponding to the human brain.
That's why it is so important to keep all of the "crutches" as
is possible in order to more closely match how the receiver of
your communication will be thinking.
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 du...@Franz.COM (internet)
Barry Margolin
Josef Eschgfaeller <e...@felix.unife.it> wrote:
> writing a letter. Also in letters some structure is useful,
> This applies also to C and most other languages.
I think you don't realize how much structure there is in written language.
Kent will probably say this better (and more verbosely), but I thought I'd
mention it.
Your basic point seems to be that indentation is redundant, since all the
structure is inherent in the parentheses. But humans generally comprehend
things more quickly when there is a certain amount of redundancy. For
instance, the commas that have appeared in this paragraph so far are mostly
redundant, because the words around them indicate the clause separations,
but using punctuation to set off clauses makes them easier to see than just
using words. Similarly, capital letters at sentence beginnings and extra
spaces after sentence ends should be unnecessary, but they help as well.
Here's a repeat of this paragraph with all these redundant features
removed:
your basic point seems to be that indentation is redundant since all the
structure is inherent in the parentheses. but humans generally comprehend
things more quickly when there is a certain amount of redundancy. for
instance the commas that have appeared in this paragraph so far are mostly
redundant because the words around them indicate the clause separations
but using punctuation to set off clauses makes them easier to see than just
using words. similarly capital letters at sentence beginnings should be
unnecessary but they help as well.
Barry Margolin
Paolo Amoroso <amo...@mclink.it> wrote:
>I seem to have read that the first Lisp books, published around the
>sixties, used a style similar to yours for code samples--i.e. without
>indentation. Maybe someone in this group can explain why this changed in
>later decades.
Because we learned from experience that non-indented code was hard to
understand.
Hrvoje Niksic
> I have been following the discussion waiting for someone to give a
> reference to something which gives the canonical way to indent Lisp
> code. (Yes, I rely on Emacs to format things on correctly when I can
> run Emacs but would like to know what the rules are so that I can
> maintain the proper indention when I can't run Emacs.) Would you
> please post a reference to the canonical way?
I'm not aware of a canonical description, so I'll try to describe what
Emacs does. There are several cases.
* Nesting with one word following open paren; indent by one space
relative to the paren.
(+
1
2)
(nconc
(list
1)
2)
(copy-list
'(bar
baz))
(copy-tree
'(((1
2))))
* Nesting with several words following open paren indent; indent by as
much as the first word takes up.
(setq foo 1
bar 2)
* Special forms that evaluate their bodies; ident the body forms by
two spaces.
(when CONDITION
BODY...)
(let ((VAR1 VALUE1)
(VAR2 VALUE2)
...)
BODY...)
(defun sqr (n)
(* n n))
(setq my-sqr (lambda (n)
(* n n)))
Emacs indents IF's THEN-clause by four spaces, and its ELSE-clauses
with two spaces.
(defun fact (n)
(if (zerop n)
1
(* n (fact (1- n)))))
CL programmers seem to prefer indenting ELSE-clauses by four spaces
too.
Barry Margolin
Hrvoje Niksic <hni...@srce.hr> wrote:
>Emacs indents IF's THEN-clause by four spaces, and its ELSE-clauses
>with two spaces.
>
>(defun fact (n)
> (if (zerop n)
> 1
> (* n (fact (1- n)))))
>
>CL programmers seem to prefer indenting ELSE-clauses by four spaces
>too.
It has to do with whether the dialect's IF allows multiple else-clauses or
just a single one. When there can be multiple else-clauses, as in Emacs
Lisp, it's like a body form, so it gets indented 2 spaces. Also, you want
the grouping of the else-clauses to be apparent, so they share a distinct
indentation level that causes them to stand off from the then-clause.
In CL, the then-clause and else-clause are more equal -- they're both just
a single expression. In this case, there's no justification to give them
different indentations.
John Wiseman
> Emacs indents IF's THEN-clause by four spaces, and its ELSE-clauses
> with two spaces.
>
> (defun fact (n)
> (if (zerop n)
> 1
> (* n (fact (1- n)))))
>
> CL programmers seem to prefer indenting ELSE-clauses by four spaces
> too.
Not this programmer. This seems like a great time for me to ask how
to make emacs indent IF like this (the way FRED, the Macintosh Common
Lisp editor, does it):
(if (...)
(...)
(...))
Thanks,
John
Christopher Browne
Interesting.
Emacs does this "right" in Scheme mode, but does the "lesser"
indentation for the "else" in Lisp mode.
I don't think I like that...
--
"Be humble. A lot happened before you were born." - Life's Little
Instruction Book
cbbr...@ntlug.org- <http://www.hex.net/~cbbrowne/langlisp.html>
Pierre R. Mai
> [Good material not needed for my question removed...]
>
> >way of indenting (especially in Lisp, where there is a canonical way),
>
> I have been following the discussion waiting for someone to give a
> reference to something which gives the canonical way to indent Lisp
> code. (Yes, I rely on Emacs to format things on correctly when I can
> run Emacs but would like to know what the rules are so that I can
> maintain the proper indention when I can't run Emacs.) Would you
> please post a reference to the canonical way?
Someone has already posted a description of what (GNU/X) Emacs does.
I'm not aware of any written specification for indentation. In effect
most of the rules of indentation are passed on from generation to
generation by code. This is made easier by the fact that most CL
constructs fall into a small number of categories, which follow very
simple rules. The most important rule is that indentation of the body
(if there is any) of a construct, and that of special arguments
differs, i.e. the one is normally 2, the other often 4, unless it is
put directly on the first line of the form:
(defun abc (dddd)
(bla)
(blub))
vs.
(defun abc
(dddd)
(bla)
(blub))
There are some slight differences in indentation styles (like in the
case of if), but none that diverge noticably, so that the basic rules
(e.g. parentheses stay on the same line, basic indentation size is 2,
special indentation is 4, etc.) are never violated.
Of course the most canonical way of indenting ANSI Common Lisp code is
given by PPRINT, which is part of every ANSI CL, although the precise
algorithm used for pretty printing isn't mandated by the ANSI spec,
and so there are some slight differences in different implementations
of pprint.
You could also look up the algorithm used by XP (the reference
implementation of a pretty-printer, by Richard C. Waters). That
should give you a good understanding of indenting Common Lisp code.
Regs, Pierre.
Tom Breton
> I'm not aware of a canonical description, so I'll try to describe what
> Emacs does. There are several cases.
>
> * Nesting with one word following open paren; indent by one space
> relative to the paren.
[...]
> * Nesting with several words following open paren indent; indent by as
> much as the first word takes up.
I sense the beginning of a one-true-indentation-style war. FWIW,
Emacs doesn't do that with me, because my lisp hook sets
( setq lisp-indent-offset 2 ) ;;Indent more comfortably.
--
Tom Breton, http://world.std.com/~tob
Ugh-free Spelling (no "gh") http://world.std.com/~tob/ugh-free.html
Vassil Nikolov
Josef Eschgfaeller wrote:
[...]
> > What do you mean by `shapes'?
>
> Something as the interior or logical shape. I meant approximately
> that when you have ready such a shape, you can put in easily the
> constructions in your program. In some sense indentation means that
> you never make that effort and so you are compelled each time to
> begin from new.
Could it be you mean that indented code could not be copied and
pasted from one program to another?? (I am still trying to grasp
the meaning of `shape' in this context. Would the word `form' (as in
`a form to be filled-in') be more appropriate than `shape'?)
[...]
> > However, what if there is a DO within a DO? Wouldn't it take
> > time to disentangle one from the other?
>
> Perhaps it could also be a reason to avoid or reorganize too
> complicated structures.
Sometimes this means to avoid too complicated problems. I agree
this makes life easier...
[...]
> Lisp is a rich and
> deep language and I have still much to learn.
By the way, it does indeed take some extra effort to learn Lisp
mode (of Emacs, for one who is just using fundamental mode),
but this effort pays off very handsomely (writing Lisp programs,
of course, not writing letters).
Good luck,
Vassil.
Marco Antoniotti
mkga...@cs.uiuc.edu (Mark K. Gardner) writes:
> I have been following the discussion waiting for someone to give a
> reference to something which gives the canonical way to indent Lisp
> code. (Yes, I rely on Emacs to format things on correctly when I can
> run Emacs but would like to know what the rules are so that I can
> maintain the proper indention when I can't run Emacs.)
^^^^^^^^^^^^^^^^^^^^^^
Isn't there an Emacs for the Palm Pilot? :)
Marco Antoniotti
amo...@mclink.it (Paolo Amoroso) writes:
I kinda prefer
"Let's keep going like this, let's hurt ourselves"
From the movie "Bianca" by Nanni Moretti (of "Dear Diary" fame).
Cheers
Marco Antoniotti
Duane Rettig <du...@franz.com> writes:
> Incidentally, writing programs is also a form of communication in
> several ways; when I write a program I am communicating to three
> classes of receivers:
> 1. The computer.
> 2. Other programmers, who don't necessarily know my design.
> 3. Myself, six months after I wrote the program.
>
> By far, the most challenging receiver to communicate with is #3.
>
I gave up on #3 many years ago :)
Erik Naggum
| The problem of indentation is interesting for me, because most
| programmers stick to it as if it were an axiom.
from here, it seems you stick to your non-indentation line with something
other than willingness to listen to good advice. I'm not sure that's an
impression you want to give.
| I had a similar discussion several years ago about C, and I was not able
| to convince anybody.
well, that often happens when one is mistaken.
| (1) Writing a program should be similar as far as possbile to writing a
| letter.
of all the things it could be similar to, why a _letter_?
| Also in letters some structure is useful, but it should be esthetic and
| functional, not ritual. This applies also to C and most other languages.
funny you say that, since "aesthetic and functional" is what indentation
is all about. it seems, however, that _you_ think it is a ritual, and
that sends some fairly strong signals that you're doing something wrong.
indeed, it seems you format your code as a ritual _today_.
| (2) More specifically in Lisp I try to memorize (and to teach to
| memorize) the shapes which can appear.
you _teach_ Lisp, too? those of us who think that Lisp's image among
young programmers suffers from bad teachers just got a very unwelcome
confirmation of our worst fears. really, you're doing your students a
huge disservice by teaching a view that you admit is really unique. I'm
profoundly sorry to see that people who cannot otherwise convince others
choose to teach those who are unlikely to object to abject silliness.
| For example: "A do has the following structure ... Therefore, when you
| see a do, look first at the assignments, then at the break-condition and
| the result, then at the single instructions." And so on. In my opinion
| this is a good training, and after little time one has no more need to
| study the indentations, which also takes time and distracts.
this sounds like a struggling beginner's view, a beginner who struggles
because he's doing something wrong and don't want to change his ways.
| Of course, when I write on the computer (I'm using Emacs, but always only
| in fundamental mode), I verify the balance of parentheses with the editor.
"always in fundamental mode"? there should be a law against that.
| But I find it useful to write simple functions first by hand and to
| control by myself the parentheses. I don't find it difficult. With this
| training the )))))))))))))))-boing disappears quickly.
I use M-( and M-) and move and manipulate complete forms when possible.
that is, I don't have unbalanced parens to begin with.
| It was on this list (or perhaps in a paper of Kent Pitman) where I read
| some days ago that in computer science sometimes first habits become
| sanctified.
yes, this often happens to people who don't engage in introspection.
| In part this may be true also for indentation.
I'm baffled that you don't see the same argument in your non-indentation.
| Perhaps, but this is a personal argument, it is also a question of eyes.
| For me it takes more time to control the indentation (with more rows to
| read) than to examine the structure.
and this is _why_ first habits become sanctified: it takes some effort to
change your ways, and lazy people who don't engage in introspection and
so constantly look for better ways to do what they do, don't ever expend
that effort. so, right now, your non-indentation is the easiest for you,
simply because you have never indented your code, never learned to use
the power of Emacs and its programmer-friendly modes, and have not seen
any reason to change your ways despite not being able to convince anyone
that your ways are superior.
I'm frankly amazed that you think _others_ are stubborn.
here's my suggestion: use PPRINT on your forms to see how Common Lisp is
most commonly formatted. learn to appreciate what people have done
before you and try to understand why they have done it that way, instead
of believing everybody else is doing silly things out of "ritual" and in
terms of "convictions" and yours is the only reasonable way to do things.
e.g.,
(pprint '
(defun num-list (a b &optional (d 1))
(do ((x a (+ x d)) (li nil))
((> x b) (nreverse li)) (push x li))))
produces, with *PRINT-RIGHT-MARGIN* at 40 and *PRINT-CASE* to :DOWNCASE:
(defun num-list (a b &optional (d 1))
(do ((x a (+ x d)) (li nil))
((> x b) (nreverse li))
(push x li)))
with *PRINT-RIGHT-MARGIN* set to 72 (the default, sort of), we get
(defun num-list (a b &optional (d 1))
(do ((x a (+ x d)) (li nil)) ((> x b) (nreverse li)) (push x li)))
which may not look great, but this is because (1) normal programmers
don't use one-letter names of variables unless they are temporary
variables with no particular meaning, anyway, so if a normal Lisp
programmer would have written this, it'd look more like this, apart from
the non-obvious utility of the function and the attendant difficulty of
finding a good name for it:
(defun number-list (from to &optional (step 1))
(do ((element from (+ element step)) (list nil))
((> element to) (nreverse list))
(push element list)))
I would expect a seasoned Lisp programmer not to write this as a function
at all, but rather just write (loop for n from <from> to <to> collect n)
instead of (number-list <from> <to>), since there is nothing to be gained
by writing functions that don't do anything to either help read the code
or partition abstraction. after all, we expect some of the code in even
the highest-level source code to use some normal Common Lisp forms; we
don't write macros and special functions for _everything_.
#:Erik
--
@1999-07-22T00:37:33Z -- pi billion seconds since the turn of the century
Erik Naggum
| This seems like a great time for me to ask how to make emacs indent IF
| like this (the way FRED, the Macintosh Common Lisp editor, does it):
|
| (if (...)
| (...)
| (...))
it depends on which Lisp mode you're using. I have
(put 'if 'lisp-indent-function 1)
(put 'if 'fi:lisp-indent-hook 1)
somewhere in the setup files. (Emacs' Lisp indentation code is arcane.)
Tim Bradshaw
> (defun number-list (from to &optional (step 1))
> (do ((element from (+ element step)) (list nil))
> ((> element to) (nreverse list))
> (push element list)))
>
> I would expect a seasoned Lisp programmer not to write this as a function
> at all, but rather just write (loop for n from <from> to <to> collect n)
> instead of (number-list <from> <to>), since there is nothing to be gained
> by writing functions that don't do anything to either help read the code
> or partition abstraction. after all, we expect some of the code in even
> the highest-level source code to use some normal Common Lisp forms; we
> don't write macros and special functions for _everything_.
>
But if you use a code style which makes it very hard to read things
like nested loops, you are likely forced into a whole bunch of tiny
functions like this...
--tim
Tim Bradshaw
>> However, what if there is a DO within a DO? Wouldn't it take
>> time to disentangle one from the other?
> Perhaps it could also be a reason to avoid or reorganize too
> complicated structures.
I think this must be commented on. Two nested loops (DO or other) are
an extremely common idiom when processing 2d arrays. You can't in all
seriousness suggest that one should avoid or reorganise structures
this complex: if a programming style is making this hard to read then
it has serious problems.
--tim
Eli Barzilay
> Perhaps it could also be a reason to avoid or reorganize too
> complicated structures.
> ...
> The danger is, as in natural language, that one does not more read
> with attention what is written. People who are accustomed to read
> much, usually can understand easily texts of considerable
> complexity.
The whole point of comparing natural language to programs is bogus.
When you write English sentences (or any other language), you never
get them too deep. Try looking at texts that you wrote and find the
longest sentence, then find the longest function you wrote.
Breaking up complicated structures is certainly good, but even very
small functions are much more complex than average natural language
sentences. Almost any quick experiment will do, something like:
(defun memo (fn &key (key #'first) (test #'eql) name)
"Return a memo-function of fn."
(let ((table (make-hash-table :test test)))
(setf (get name :memo) table)
#'(lambda (&rest args)
(let ((k (funcall key args)))
(multiple-value-bind (val found-p)
(gethash k table)
(if found-p
val
(setf (gethash k table) (apply fn args))))))))
translates into an English sentence like:
The memoization of a function fn using a key which defaults to the
first function and a test that defaults to eql function and an
optional name argument is: take table as a new hash table with a
test as its test function, set the :memo property of the name
argument to the table and return a function that gets a list of
arguments and now let k be the result of calling the key argument on
the given list of arguments, then let val and found-p be the value
of k in the table and if it was found there, then, if found-p is
true then return val else set the value associated with k in the
table to the result of applying fn to the arguments and return this
value.
I hope that demonstrates the point... If you write such sentences,
then you probably have no problems reading
(defun memo (fn &key (key #'first) (test #'eql) name) "Return a
memo-function of fn." (let ((table (make-hash-table :test test)))
(setf (get name :memo) table) #'(lambda (&rest args) (let ((k (funcall
key args))) (multiple-value-bind (val found-p) (gethash k table) (if
found-p val (setf (gethash k table) (apply fn args))))))))
This can be added to the point made by Barry Margolin in
<gC8e3.1026$KM3.239358@burlma1-snr2>.
> >> (defun num-list (a b &optional (d 1))
> >> (do ((x a (+ x d)) (li nil))
> >> ((> x b) (nreverse li)) (push x li)))
BTW, if indentation is completely unimportant, why did you put the
newlines in those places? Why did you put spaces around some parens
where it is not needed?
And if you insist on using this style in public, then why do you put
these "> " prefixes to stuff you quoted?
Last point - I may not have seen too much, but I have a rough rule
that the quality of a programmer is directly related to the style of
his/her programs, and in about 10 years, I never saw a counter
example... I saw terrible programmers that just added statements
wherever the cursor was placed (which sometime was whatever random
point was clicked to get the window to the front), and I saw amazing
programmers (a lot, especially around Lisp and relatives) that insist
on strict comment style, spacing style not to mention indentation...
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://www.cs.cornell.edu/eli/meaning.html Maze is Life!
Kent M Pitman
> On Tue, 29 Jun 1999 05:13:05 +0300, Vassil Nikolov <vnik...@poboxes.com>
> wrote:
>
> > I don't think that writing a program is very similar to writing
> > a letter, or to writing a poem, or a short story, or whatever.
>
> Incidentally, organizing and writing source code as part of a larger prose
> text documenting the system is the main idea behind Knuth's "literate
> programming".
To state my opinion on this, we need to distinguish between "truth"
and the stronger "necessary truth". Mere truth being something that
could be false under other circumstances, like "there are 9 planets".
Necessary truth being something that could not be otherwise, like
2+2=4. It is certainly true that writing a program is not similar
to writing prose, but it is far from necessarily true. And I don't
think it's desirable that they're different. One reason programs
are fragile (subject to the most meager bugs that nitpicky computer
scientists revel in but "normal" people have no experience with at all)
is that they use a notation where any single-bit-error is enough to
make a program not work. Consider how it would be if a novel (or even
a note about what groceries to buy left to a spouse on a refrigerator)
were rendered utterly unreadable by a single misspelling... Redundancy
is something we have bred a culture to hate, but it is something that
has served nature and humanity quite well. Although computer people
have a lot to teach the real world, so too does the real world have a
lot to teach computer people.
Kent M Pitman
> [Josef Eschgfaeller wrote:]
> >>>> (defun num-list (a b &optional (d 1))
> >>>> (do ((x a (+ x d)) (li nil))
> >>>> ((> x b) (nreverse li)) (push x li)))
> >
> > When I look at the above code, I can't easily tell if it's iterating one
> > variable or two.
>
> I think that particular example is pretty clear, simply because
> it's so short and structurally simple. But I wonder what Josef
> would make of something like this:
>
> (defun knapsack0 (annotated-set bound min trunc) (when (or (null
> annotated-set) (<= bound trunc)) (return-from knapsack0 (values nil
> 0))) (let* ((first-item (car annotated-set)) (remaining-set (cdr ...
This is cute but not a fair example.
English is optimized to have topic sentences in paragraphs. You can read
the topic sentence and know whether you want to read the other sentences.
At least, when paragraphing is done right. It is possible to use bad
style in any language.
English also breaks on sentence boundaries that are clearly marked and
does not employ serious nesting--in fact it has rules that work to
make you have to form a new sentence rather than run on except when
the run-on is a tail-call, that is, a subordinate clause or apositive
expression that can be understood in isolation without referring back
structurally, as happens a lot in this sentence. English with no periods
or commas is more like unground code--losing much of the differentiation
that makes it possible to skim instead of read linearly.
[If you don't know what "unground" means, it means "not pretty printed".
In early Maclisp, years ago, the pretty printer was not very reliable
and there was a function GRIND (named after a meat grinder, I think) that
was willing to try to read a file and pretty-print it back. It didn't
always come out better for the process, so the name was apt. Pretty
printing your code was in Maclisp called "grinding your code".]
> It's certainly not *impossible* to read this without any
> indentation. But it's pretty unpleasant. Here's a quick
> test.
>
> - What is the role of ITEM in line 4? Function being called,
> variable being bound, or something else? [etc]
All that you can conclude from questions like this is that if you mess
up the formatting then it's harder to read. With English, as
with Lisp, grinding your text makes certain relationships more
apparent but makes the text take up more room. On the other
hand, if you fail to grind your
English, then it doesn't become unreadable, like it does in Lisp.
All that you can conclude from questions like this
is that
if you mess up the formatting
then it's harder to read.
With English,
as with Lisp,
grinding your text
makes certain relationships more apparent
but makes the text take up more room.
On the other hand,
if you fail to grind your English,
then it doesn't become unreadable,
like it does in Lisp.
The ANSI CL source is full of weird formattings like this, btw. It
helped me catch innumerable numbers of errors in parallel construction
because my visual hardware was able to capture what reading could not.
So to some degree the difference isn't in the language, in this case,
nor even the task, but in the convention.
Marco Antoniotti
Tom Breton <t...@world.std.com> writes:
> Hrvoje Niksic <hni...@srce.hr> writes:
>
>
> > I'm not aware of a canonical description, so I'll try to describe what
> > Emacs does. There are several cases.
> >
> > * Nesting with one word following open paren; indent by one space
> > relative to the paren.
> [...]
> > * Nesting with several words following open paren indent; indent by as
> > much as the first word takes up.
>
> I sense the beginning of a one-true-indentation-style war. FWIW,
> Emacs doesn't do that with me, because my lisp hook sets
> ( setq lisp-indent-offset 2 ) ;;Indent more comfortably.
I *HATE* the space after '(' and the one before ')'. :)
Let's have a PARENTHESIS fight! :)
Gareth McCaughan
[I wrote:]
>> (defun knapsack0 (annotated-set bound min trunc) (when (or (null
>> annotated-set) (<= bound trunc)) (return-from knapsack0 (values nil
>> 0))) (let* ((first-item (car annotated-set)) (remaining-set (cdr ...
>
> This is cute but not a fair example.
[SNIP: the role of punctuation etc in English]
I'm not sure why that makes what I wrote "not a fair example".
Josef was seriously claiming that indentation in code is useless.
I posted some unindented code and gave some evidence that it
would have been helped by indentation. I don't understand what's
unfair.
(Almost certainly it's I who am missing something here.)
> English with no periods
> or commas is more like unground code--losing much of the differentiation
> that makes it possible to skim instead of read linearly.
I thought that was exactly what I was claiming.
>> It's certainly not *impossible* to read this without any
>> indentation. But it's pretty unpleasant. Here's a quick
>> test.
>>
>> - What is the role of ITEM in line 4? Function being called,
>> variable being bound, or something else? [etc]
>
> All that you can conclude from questions like this is that if you mess
> up the formatting then it's harder to read.
I thought that was exactly what I was claiming.
--
Gareth McCaughan Dept. of Pure Mathematics & Math. Statistics,
Gareth.M...@pobox.com Cambridge University, England.
Erik Naggum
| Let's have a PARENTHESIS fight! :)
your parens wear army boots!
Hrvoje Niksic
> Hrvoje Niksic <hni...@srce.hr> writes:
>
>
> > I'm not aware of a canonical description, so I'll try to describe
> > what Emacs does. There are several cases.
> >
> > * Nesting with one word following open paren; indent by one space
> > relative to the paren.
> [...]
> > * Nesting with several words following open paren indent; indent by as
> > much as the first word takes up.
>
> I sense the beginning of a one-true-indentation-style war.
Why? The question was about the common Lisp indentations (what a bad
pun!) and I simply tried to provide a fair answer.
> FWIW, Emacs doesn't do that with me, because my lisp hook sets
> ( setq lisp-indent-offset 2 ) ;;Indent more comfortably.
OK, I should have said "what Emacs does by default." Happy?
(And parens between after the opening and before the closing paren are
horrible! :-) )
Kent M Pitman
> (Almost certainly it's I who am missing something here.)
Oh, not necessarily. Might be me. Sounds like I misinterpreted your
intent.
The basic point I was answering was probably in earlier messages, where
there were assertions that Lisp and English were different, and I thought
it was being proposed that indentation was part of the difference, and that
showing that it didn't work without was an illustration of that. It was
a long thread and I admit I was skimming.
Sounds like we're not in disagreement on this. Thanks for the clarification.
> > All that you can conclude from questions like this is that if you mess
> > up the formatting then it's harder to read.
>
> I thought that was exactly what I was claiming.
Ah, ok.
Stig Hemmer
> If you want others to be able to read your code, you have to conform
> to the standard indenting conventions. Debate is pointless. You will
> lose big if you refuse to indent your code in the canonical way.
I feel that this is a bit strong.
I mean, consider:
(defun wobble (x)
(if (> x 0)
'positive
'not-positive))
(defun wobble (x)
(if (> x 0)
'positive
'not-positive))
(defun wobble (x)
(if (> x 0)
'positive
'not-positive))
or even
(defun wobble (x)
(if (> x 0)
'positive
'not-positive))
All these are very readable. You might stumble for a second if you
are used to a different scheme, but nothing more than that.
However, what is _not_ OK is to not indent at all. That makes code
unreadable for most of us. Indent early, indent often.
Stig Hemmer,
Jack of a Few Trades.
Duane Rettig
> r...@nightfly.apk.net (R. Matthew Emerson) writes:
> > If you want others to be able to read your code, you have to conform
> > to the standard indenting conventions. Debate is pointless. You will
> > lose big if you refuse to indent your code in the canonical way.
>
> I feel that this is a bit strong.
It is only strong to the extent that you place strength in the
word "conform". If to you it means to be exactly alike, then it
is of course strong.
However, this thread has not been about "the one, true indentation
style" (in fact, attempts to bring that into the picture were quickly
and appropriately laughed down; perhaps the attempts themselves were
jokes). Rather, this thread has been about making some effort - any
effort - to make code as readable as possible.
> I mean, consider:
>
> (defun wobble (x)
> (if (> x 0)
> 'positive
> 'not-positive))
>
> (defun wobble (x)
> (if (> x 0)
> 'positive
> 'not-positive))
>
> (defun wobble (x)
> (if (> x 0)
> 'positive
> 'not-positive))
>
> or even
>
> (defun wobble (x)
> (if (> x 0)
> 'positive
> 'not-positive))
>
> All these are very readable. You might stumble for a second if you
> are used to a different scheme, but nothing more than that.
Yes, they are readable, and thus "conform" even though they are not
identical.
> However, what is _not_ OK is to not indent at all. That makes code
> unreadable for most of us. Indent early, indent often.
Precisely.
> Stig Hemmer,
> Jack of a Few Trades.
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 du...@Franz.COM (internet)
Tom Breton
> Tom Breton <t...@world.std.com> writes:
>
> > FWIW, Emacs doesn't do that with me, because my lisp hook sets
> > ( setq lisp-indent-offset 2 ) ;;Indent more comfortably.
>
> OK, I should have said "what Emacs does by default." Happy?
FWIW means "For what it's worth", which is to say, here comes a
tangential comment you may not neccessarily value.
> (And parens between after the opening and before the closing paren are
> horrible! :-) )
It's advice I got from Code Complete some years ago: Use whitespace
liberally to improve legibility. Whitespace is cheap these days.
Tom Breton
> r...@nightfly.apk.net (R. Matthew Emerson) writes:
> > If you want others to be able to read your code, you have to conform
> > to the standard indenting conventions. Debate is pointless. You will
> > lose big if you refuse to indent your code in the canonical way.
>
> I feel that this is a bit strong.
>
> I mean, consider:
>
> (defun wobble (x)
> (if (> x 0)
> 'positive
> 'not-positive))
>
> (defun wobble (x)
> (if (> x 0)
> 'positive
> 'not-positive))
>
> (defun wobble (x)
> (if (> x 0)
> 'positive
> 'not-positive))
Indeed, my first reaction was "Why'd he write the same exact thing 3
times?" The 4th is more obviously different, but still easily the
same code.
> (defun wobble (x)
> (if (> x 0)
> 'positive
> 'not-positive))
Marco Antoniotti
Tom Breton <t...@world.std.com> writes:
Just to be very annoying :) I claim that example 4 is disgusting.
The VI+tab indentation style - i.e. without any reference to actual
code structure - irks me :) As a matter of fact you see *a lot* of C
code formatted that way.
Fernando Mato Mira
> code structure - irks me :) As a matter of fact you see *a lot* of C
> code formatted that way.
C'mon. Why don't you just say you hate people that use more than 2 spaces as
indentation tab? ;->
Marco Antoniotti
That's an idea :)
Barry Margolin
Tom Breton <t...@world.std.com> wrote:
>Hrvoje Niksic <hni...@srce.hr> writes:
>> (And parens between after the opening and before the closing paren are
>> horrible! :-) )
>
>It's advice I got from Code Complete some years ago: Use whitespace
>liberally to improve legibility. Whitespace is cheap these days.
I find that whitespace between the parens and the text decreases
legibility. I think that most experienced Lisp programmers tend to gloss
over the parens -- this is why indentation is so important. But when you
set them apart with whitespace, they stick out too much.
The only context in which I put whitespace around parens is in C-shell
scripts (which I try to avoid writing, so this is mainly just my .login and
.cshrc), because it's known to have a buggy parser that sometimes screws up
around parens. It could also be excused in Lisp if you're writing a
tabular data structure and want to line up all the columns in an esthetic
way, e.g.
(defvar *thing-alist*
'(( 1 . foo )
( 23 . abcd )
(100 . x )
( 99 . aaaaa)))
--
Barry Margolin, bar...@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Bruce R Miller
Marco Antoniotti <mar...@copernico.parades.rm.cnr.it> writes:
>
> Tom Breton <t...@world.std.com> writes:
>
>> Stig Hemmer <st...@pvv.ntnu.no> writes:
>> Indeed, my first reaction was "Why'd he write the same exact thing 3
>> times?" The 4th is more obviously different, but still easily the
>> same code.
> ... As a matter of fact you see *a lot* of C
> code formatted that way.
Hmm, my first reaction was "Why'd he write the same exact thing 3 times
and then translate it into C the fourth time ? --- Oh, that isn't C"
Christopher Browne
>* Marco Antoniotti <mar...@copernico.parades.rm.cnr.it>
>| Let's have a PARENTHESIS fight! :)
>
> your parens wear army boots!
Now, now...
Remember that any time you participate in a dung fight, it doesn't
matter if you "win" or "lose," you still wind up smelling really bad.
[The implications should be obvious :-).]
--
"... Turns out that JPG was in fact using his brain... and I am inclined to
encourage him to continue the practice even if it isn't exactly what I
would have done myself." -- Alan Bawden (way out of context)
cbbr...@ntlug.org- <http://www.ntlug.org/~cbbrowne/langlisp.html>