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

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

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.

mkgar...@cs.uiuc.edu (Mark K. Gardner) writes:

Isn't there an Emacs for the Palm Pilot? :)

        "Let's keep going like this, let's hurt ourselves"

From the movie "Bianca" by Nanni Moretti (of "Dear Diary" fame).

Cheers

Cheers

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

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

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?

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".]

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.

Let's have a PARENTHESIS fight! :)

Cheers

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

  your parens wear army boots!

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.

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.

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.

Cheers