From: Josef Eschgfaeller
Subject: Indentation
Date: 
Message-ID: <Pine.LNX.4.04.9906290415480.14093-100000@arbzi.zuhause.fe>
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

From: Johan Kullstam
Subject: Re: Indentation
Date: 
Message-ID: <m2emiv7p7f.fsf@sophia.axel.nom>
Josef Eschgfaeller <···@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.

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
[········@ne.mediaone.net]
Don't Fear the Penguin!
From: thi
Subject: Re: Indentation
Date: 
Message-ID: <m2rso7bh556.fsf@netcom9.netcom.com>
Josef Eschgfaeller <···@felix.unife.it> writes:

> The problem of indentation is interesting for me, because most

so you make it a problem for other people too?

thi
From: Paolo Amoroso
Subject: Re: Indentation
Date: 
Message-ID: <377aed28.1113632@news.mclink.it>
On Tue, 29 Jun 1999 04:23:38 +0200, Josef Eschgfaeller <···@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

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
-- 
Paolo Amoroso <·······@mclink.it>
From: Barry Margolin
Subject: Re: Indentation
Date: 
Message-ID: <gC8e3.1026$KM3.239358@burlma1-snr2>
In article <········································@arbzi.zuhause.fe>,
Josef Eschgfaeller  <···@felix.unife.it> wrote:
>(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.

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, ······@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.
From: R. Matthew Emerson
Subject: Re: Indentation
Date: 
Message-ID: <87u2rrhivf.fsf@nightfly.apk.net>
Josef Eschgfaeller <···@felix.unife.it> writes:

> (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
From: Stig Hemmer
Subject: Re: Indentation
Date: 
Message-ID: <ekvg138us0o.fsf@verden.pvv.ntnu.no>
···@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))

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.
From: Duane Rettig
Subject: Re: Indentation
Date: 
Message-ID: <4hfnom9f7.fsf@beta.franz.com>
Stig Hemmer <····@pvv.ntnu.no> writes:

> ···@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   ·····@Franz.COM (internet)
From: Tom Breton
Subject: Re: Indentation
Date: 
Message-ID: <m39090kkyp.fsf@world.std.com>
Stig Hemmer <····@pvv.ntnu.no> writes:

> ···@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))


-- 
Tom Breton, http://world.std.com/~tob
Ugh-free Spelling (no "gh") http://world.std.com/~tob/ugh-free.html
From: Marco Antoniotti
Subject: Re: Indentation
Date: 
Message-ID: <lwd7ybmq7q.fsf@copernico.parades.rm.cnr.it>
Tom Breton <···@world.std.com> writes:

> Stig Hemmer <····@pvv.ntnu.no> writes:
> 
> > ···@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))
> 

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.

Cheers

-- 
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
From: Bruce R Miller
Subject: Re: Indentation
Date: 
Message-ID: <7lium5$4qc$1@news.nist.gov>
In article <··············@copernico.parades.rm.cnr.it>,
	Marco Antoniotti <·······@copernico.parades.rm.cnr.it> writes:
> 
> Tom Breton <···@world.std.com> writes:
> 
>> Stig Hemmer <····@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"

-- 
--
············@nist.gov
http://math.nist.gov/~BMiller/
From: Fernando Mato Mira
Subject: Re: Indentation
Date: 
Message-ID: <377C8358.45822FDF@iname.com>
Marco Antoniotti wrote:

> 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? ;->
From: Marco Antoniotti
Subject: Re: Indentation
Date: 
Message-ID: <lw4sjnmkjy.fsf@copernico.parades.rm.cnr.it>
Fernando Mato Mira <········@iname.com> writes:

> Marco Antoniotti wrote:
> 
> > 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? ;->

That's an idea :)

Cheers

-- 
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
From: Vassil Nikolov
Subject: Re: Indentation
Date: 
Message-ID: <l03130300b39dd582cc4e@195.138.129.57>
On 1999-06-29 04:23 +0200,
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: ········@poboxes.com
For more: http://www.poboxes.com/vnikolov
  Abaci lignei --- programmatici ferrei.
From: Paolo Amoroso
Subject: Re: Indentation
Date: 
Message-ID: <3779ed25.1111121@news.mclink.it>
On Tue, 29 Jun 1999 05:13:05 +0300, Vassil Nikolov <········@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".


Paolo
-- 
Paolo Amoroso <·······@mclink.it>
From: Kent M Pitman
Subject: Re: Indentation
Date: 
Message-ID: <sfwpv2ddoh0.fsf@world.std.com>
·······@mclink.it (Paolo Amoroso) writes:

> On Tue, 29 Jun 1999 05:13:05 +0300, Vassil Nikolov <········@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.
From: Marco Antoniotti
Subject: Re: Indentation
Date: 
Message-ID: <lwlnd3k2dk.fsf@copernico.parades.rm.cnr.it>
Josef Eschgfaeller <···@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
From: Paolo Amoroso
Subject: Re: Indentation
Date: 
Message-ID: <3778f1a1.2258727@news.mclink.it>
On 29 Jun 1999 07:21:59 +0200, Marco Antoniotti
<·······@copernico.parades.rm.cnr.it> wrote:

> Josef Eschgfaeller <···@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!".


Paolo
-- 
Paolo Amoroso <·······@mclink.it>
From: Marco Antoniotti
Subject: Re: Indentation
Date: 
Message-ID: <lwn1xidosd.fsf@copernico.parades.rm.cnr.it>
·······@mclink.it (Paolo Amoroso) writes:

> On 29 Jun 1999 07:21:59 +0200, Marco Antoniotti
> <·······@copernico.parades.rm.cnr.it> wrote:
> 
> > Josef Eschgfaeller <···@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!".

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 ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
From: Andy Freeman
Subject: Re: Indentation
Date: 
Message-ID: <7la006$agj$1@nnrp1.deja.com>
In article <········································@arbzi.zuhause.fe>,
  Josef Eschgfaeller <···@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.
From: Tim Bradshaw
Subject: Re: Indentation
Date: 
Message-ID: <ey3btdz7cak.fsf@lostwithiel.tfeb.org>
* Josef Eschgfaeller wrote:

> (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
From: Gareth McCaughan
Subject: Re: Indentation
Date: 
Message-ID: <861zevjm2d.fsf@g.pet.cam.ac.uk>
Josef Eschgfaeller wrote:

> (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,
················@pobox.com  Cambridge University, England.
From: Pierre R. Mai
Subject: Re: Indentation
Date: 
Message-ID: <87btdzgo29.fsf@orion.dent.isdn.cs.tu-berlin.de>
Josef Eschgfaeller <···@felix.unife.it> writes:

> 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 <····@acm.org>         PGP and GPG keys at your nearest Keyserver
  "One smaller motivation which, in part, stems from altruism is Microsoft-
   bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
From: Mark K. Gardner
Subject: Re: Indentation
Date: 
Message-ID: <slrn7nht63.bgu.mkgardne@rtsl3.cs.uiuc.edu>
On 29 Jun 1999 14:59:26 +0200, Pierre R. Mai <····@acm.org> wrote:

[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 (········@cs.uiuc.edu)
University of Illinois at Urbana-Champaign
Real-Time Systems Laboratory
-- 
From: Hrvoje Niksic
Subject: Re: Indentation
Date: 
Message-ID: <87so7asuav.fsf@pc-hrvoje.srce.hr>
········@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.) 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.
From: Barry Margolin
Subject: Re: Indentation
Date: 
Message-ID: <Pk9e3.1031$KM3.240489@burlma1-snr2>
In article <··············@pc-hrvoje.srce.hr>,
Hrvoje Niksic  <·······@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.

-- 
Barry Margolin, ······@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.
From: John Wiseman
Subject: Re: Indentation
Date: 
Message-ID: <arxu2rqn38h.fsf@gargoyle.cs.uchicago.edu>
Hrvoje Niksic <·······@srce.hr> writes:

> 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
From: Christopher Browne
Subject: Re: Indentation
Date: 
Message-ID: <01de3.273$VY1.42828@news3.giganews.com>
On Tue, 29 Jun 1999 20:47:26 GMT, John Wiseman
<·······@cs.uchicago.edu> wrote: 
>Hrvoje Niksic <·······@srce.hr> writes:
>
>> 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 (...)
>  (...)
>  (...))

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
········@ntlug.org- <http://www.hex.net/~cbbrowne/langlisp.html>
From: Erik Naggum
Subject: Re: Indentation
Date: 
Message-ID: <3139729176190036@naggum.no>
* ·······@cs.uchicago.edu (John Wiseman)
| 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.)

#:Erik
-- 
@1999-07-22T00:37:33Z -- pi billion seconds since the turn of the century
From: Tom Breton
Subject: Re: Indentation
Date: 
Message-ID: <m3wvwmtpu4.fsf@world.std.com>
Hrvoje Niksic <·······@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.

-- 
Tom Breton, http://world.std.com/~tob
Ugh-free Spelling (no "gh") http://world.std.com/~tob/ugh-free.html
From: Marco Antoniotti
Subject: Re: Indentation
Date: 
Message-ID: <lw9090sest.fsf@copernico.parades.rm.cnr.it>
Tom Breton <···@world.std.com> writes:

> Hrvoje Niksic <·······@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! :)

Cheers

-- 
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
From: Erik Naggum
Subject: Re: Indentation
Date: 
Message-ID: <3139830633828663@naggum.no>
* Marco Antoniotti <·······@copernico.parades.rm.cnr.it>
| Let's have a PARENTHESIS fight! :)

  your parens wear army boots!

#:Erik
-- 
@1999-07-22T00:37:33Z -- pi billion seconds since the turn of the century
From: Christopher Browne
Subject: Re: Indentation
Date: 
Message-ID: <xigf3.285$F7.23516@news3.giganews.com>
On 01 Jul 1999 15:10:33 +0000, Erik Naggum <····@naggum.no> wrote:
>* Marco Antoniotti <·······@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)
········@ntlug.org- <http://www.ntlug.org/~cbbrowne/langlisp.html>
From: Hrvoje Niksic
Subject: Re: Indentation
Date: 
Message-ID: <874sjo9z23.fsf@pc-hrvoje.srce.hr>
Tom Breton <···@world.std.com> writes:

> Hrvoje Niksic <·······@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! :-) )
From: Tom Breton
Subject: Re: Indentation
Date: 
Message-ID: <m3btdwkmaw.fsf@world.std.com>
Hrvoje Niksic <·······@srce.hr> writes:

> Tom Breton <···@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, http://world.std.com/~tob
Ugh-free Spelling (no "gh") http://world.std.com/~tob/ugh-free.html
From: Barry Margolin
Subject: Re: Indentation
Date: 
Message-ID: <QF4f3.1107$KM3.249685@burlma1-snr2>
In article <··············@world.std.com>,
Tom Breton  <···@world.std.com> wrote:
>Hrvoje Niksic <·······@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, ······@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.
From: Pierre R. Mai
Subject: Re: Indentation
Date: 
Message-ID: <87zp1ifr3i.fsf@orion.dent.isdn.cs.tu-berlin.de>
········@cs.uiuc.edu (Mark K. Gardner) writes:

> [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.

-- 
Pierre Mai <····@acm.org>         PGP and GPG keys at your nearest Keyserver
  "One smaller motivation which, in part, stems from altruism is Microsoft-
   bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
From: Marco Antoniotti
Subject: Re: Indentation
Date: 
Message-ID: <lwoghydoz0.fsf@copernico.parades.rm.cnr.it>
········@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 ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
From: Barry Margolin
Subject: Re: Indentation
Date: 
Message-ID: <VX5e3.1009$KM3.238757@burlma1-snr2>
In article <········································@arbzi.zuhause.fe>,
Josef Eschgfaeller  <···@felix.unife.it> wrote:
>(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.

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, ······@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.
From: Gareth McCaughan
Subject: Re: Indentation
Date: 
Message-ID: <861zevhtcu.fsf@g.pet.cam.ac.uk>
Barry Margolin wrote:

[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.

-- 
Gareth McCaughan            Dept. of Pure Mathematics & Math. Statistics,
················@pobox.com  Cambridge University, England.
From: Kent M Pitman
Subject: Re: Indentation
Date: 
Message-ID: <sfwoghxdn8b.fsf@world.std.com>
Gareth McCaughan <················@pobox.com> writes:

> [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. 
From: Gareth McCaughan
Subject: Re: Indentation
Date: 
Message-ID: <863dz8zc4d.fsf@g.pet.cam.ac.uk>
Kent Pitman wrote:

[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,
················@pobox.com  Cambridge University, England.
From: Kent M Pitman
Subject: Re: Indentation
Date: 
Message-ID: <sfwd7ycxm8q.fsf@world.std.com>
Gareth McCaughan <················@pobox.com> writes:

> (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.
From: Erik Naggum
Subject: Re: Indentation
Date: 
Message-ID: <3139728333138511@naggum.no>
* Josef Eschgfaeller <···@felix.unife.it>
| 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
From: Tim Bradshaw
Subject: Re: Indentation
Date: 
Message-ID: <nkj1zetkj35.fsf@tfeb.org>
Erik Naggum <····@naggum.no> writes:

> (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
From: Eli Barzilay
Subject: Re: Indentation
Date: 
Message-ID: <skr9mt1bkc.fsf@tulare.cs.cornell.edu>
Josef Eschgfaeller <···@felix.unife.it> writes:

 > 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
<·····················@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!