I used to not like it but was gradually won over, though I think good
style means avoiding using its total power and sticking to things that
are straightforward to read.

The reason some people don't like it is simple syntax--it's not grouped.
Something like
 (loop for i from 0 to 100 for j from 3 for z in z-list do (something))
ought, some say, be grouped like
 (loop (for i (from-to 0 100))
       (for j (from 3))
       (for z (in z-list))
       (do (something)))
or at least
 (loop :for ((i :from 0 :to 100)
             (j :from 3)
             (z :in z-list))
       :do (something))
so that Emacs can more easily indent it or so that programs didn't need
a special parser to understand it.  Nevertheless, loop advocates defend
the syntax as simple and important to be uncluttered by the extra parens.

Ignoring the syntax, though, and just accepting that it is what it is (and
what it has been for several decades), the fact is that it provides important
capabilities of concisely representing the generation and collection of
quantities in a very useful way.  Not the only way that has ever been come
up with, but still *a* useful way.  

For a long time, I preferred to write

 (do ((l list (cdr l))
      (result '() (cons (f (car l)) result)))
     ((null l) (nreverse result)))

But though this has the usefulness of paralleling Scheme's tail recursive

 (let foo ((l list)
           (result '()))
   (if (null? l)
       (reverse! result)
       (foo (cdr l) (cons (f (car l)) result))))

in the end, I couldn't justify to new users why they shouldn't just write
the more obvious:

 (loop for item in list
       collect (f item))

And sure, you could also write

 (mapcar #'f list)

but the point is that if you want to change the accumulation from collect
to max or min, you can't make a trivial edit to fix that, whereas with the
loop one you can do

 (loop for item in list
       maximize (f item))

Likewise, things like dolist only make it easy to step the easily-steppable
data structures.  If you wanted to step a package in synch with a counter,
you'd have to mix binders. e.g.,

 (let ((i 0))
   (do-external-symbols (s "COMMON-LISP")
     (incf i))
   i) => 978

Whereas with loop you can do this in a consolidated way:

 (loop for symbol being the external-symbols of "COMMON-LISP"
       count t)
 => 978

Basicallly, a lot of standard idioms are there and it's really quite
definitely worth being able to use it.

- - -

The other things that are controversial are the fact that some aspects
of LOOP seem unnecessary at first blush.  It has conditionals, for
example.  One is sometimes led to write

 (loop for x in y
       when (f x)
         do (g x))

when one could as well write

 (dolist (x y)
   (when (f x)
     (g x)))

Looking at such an example, one might ask why WHEN is there at all.  But
the answer turns out to be that it's *very* hard to write a macro in CL
that has a "detached" piece of syntax.  So you need to have a way to get
to the collect point, and it's often in a conditional.  Consider:

 (loop for x in y
      when (f x)
       collect (g x))

This one you can't write as

 (dolist (x y)
   (when (f x)
     (collect (g x))))

Nor is there another macro (even LOOP) that you could substitute for dolist
that would make the "collect" part work.  You *could* make a special
"collecting" macro, for example, that did

 (collecting (result :type list)
   (dolist (x y)
     (when (f x)
       (collect-into result (g x)))))

but already you're in a problem where you've detached the collection from
the generation, and if you have several of these to do they get harder
and harder.

The ability in loop to do even complex things like:

 (loop for x in '(1 2 3 4 5 6 7)
    when (evenp x)
     collect x into evens
    else
     collect x into odds
    finally
     (return (values evens odds)))
 => (2 4 6), (1 3 5 7)

is considerably easier and clearer than some other alternatives.

Also, being able to vary the collection is handy.  Consider:

 (loop for x in '(a b (c d) e f)
       when (atom x)
        collect x
       else
        append x)
 => (A B C D E F)

Writing the equivalent in a dolist is trickier.  Consider:

 (let ((result '()))
   (dolist (x '(a b (c d) e f))
     (if (atom x)
         (push x result)
       (dolist (subx x)
         (push subx result))))
   (nreverse result))
 => (A B C D E F)

Now, personally, I have no trouble looking at either of these and seeing
the same thing, but I still have to admit that the LOOP form of it is
more instantly accessible not only to me but to newcomers.

Some don't like it because it seems very ALGOL-esque and they think
something Lispy would be better, but those of us who've "given in to
the dark side" basically acknowledge that sometimes other languages
have something to offer in terms of expression and it's better not to
fight things that don't seriously need fighting.   People who WANT
to not use this are still free to, but those who like LOOP are not
idiots or crazy or possessed by the devil.  They're just making  an
engineering trade-off.

Some also don't like that there are occasionally obscure things in LOOP
you have to be careful of.  It used to be in older dialects that
 (loop collect x for i from 1 to 3)
would unintuitively return (1 2 3 4) because the collection came before
the iteration test, but
 (loop for i from 1 to 3 collect x)
would return (1 2 3) as you might expect.  In ANSI CL, we've added
constraints to LOOP that say the variable stepping clauses have to
precede the collection parts, so this can't happen.  Nevertheless,
there may be a few ways you can still confuse yourself with LOOP.
For example, you might think
 (loop with i = (random 100) for x from 1 to 10 do (print (list i x)))
and
 (loop for  i = (random 100) for x from 1 to 10 do (print (list i x)))
meant the same in English, but you *must* know that FOR means to do the
action every time around the loop, while WITH means to do it only once
before starting.  This is a major difference but people who make the
mistake of thinking loop is "just English" are going to get confused
by "apparent synonyms" (a.k.a. "false cognates").  

Good LOOP style means knowing what the words really mean, and that
means that although it seems like the best entry point for the novice,
novices need to be more cautious than anyone about its use.  That
doesn't mean "don't use it", just "use it with care".  Lisp may be great
for building AI things but it does not use AI as part of its own
semantics...

| but the point is that if you want to change the accumulation from collect
| to max or min, you can't make a trivial edit to fix that, whereas with the
| loop one you can do
|
|  (loop for item in list
|        maximize (f item))

As long as we're on that topic: how can you have a (simple) loop that
maximizes return a compound structure instead of the maximized value?

Something like:

  (defclass foo ()
      ((name :accessor name)
       (weight :accessor weight)))

  (let ((foo1 (make-instance 'foo :name "foo1" :weight 10))
        (foo2 (make-instance 'foo :name "foo2" :weight 9)))
    (loop for foo in (list foo1 foo2)
          maximize (weight foo))

This will return 10.  I want it to return foo1.  Is there some easy
way to accomplish this with maximize?

--
bo...@uncommon-sense.net - <http://www.uncommon-sense.net/>

"Erik Naggum" <e...@naggum.net> wrote

Some quotes from "Being Popular" by Paul Graham, March 2001 :

"The political correctness of Common Lisp is an aberration."

"A more serious problem is the diffuseness of prefix notation. For
expert hackers, that really is a problem. No one wants to write
(aref a x y) when they could write a[x,y]."

"The good news is, it's not Lisp that sucks, but Common Lisp."

The original is there : http://www.paulgraham.com/popular.html

OK, a last funny one:

"Using first and rest means 50% more typing. And
they are also different lengths, meaning that the arguments won't
line up when they're called, as car and cdr often are, in successive
lines. "

Sigh...

 (loop with best-foo = nil   ;untested
       for foo in (list foo1 foo2)
       when (or (not best-foo)
                (> (weight foo) (weight best-foo)))
         do (setq best-foo foo)
       finally (return best-foo))

All in all, I think this is still pretty readable, though I'd accept
the classic

 (let ((best-foo nil))      ;untested
   (dolist (foo (list foo1 foo2))
     (when (or (not best-foo)
               (> (weight foo) (weight best-foo)))
       (setq best-foo foo)))
   best-foo)

 The beauty of Lisp is that function follows form.   The uninitiated often laugh at
all the parentheses in a Lisp function.   The Lisp expert however sees in those parens
the structure of the code.   It's like looking at the framework of a building being
built and being able to envision the function of every part of it.

 The loop macro ruins this.   You have an opening paren and a closing parens and then
a collection of english words with stuff in between.  There is no longer any structure
visible.  You have to read the form as you would a novel with very obscure
and convoluted sentence struture.  (see http://www.bulwer-lytton.com/ for convoluted
sentence structure examples).

 Everyone who've I've seen attracted to the loop macro starts out swearing that they
will only use it for simple loops but soon get loop fever and it's a challenge to them
to write the most obscure unreadable loop macros they can, using every single loop
macro keyword.

 my advice: Avoid loop like the plauge.  Stick with all those parens.  Make it your
goal that your code will not only work but will be readable and modifyable by others.
Yes it may take more characters to write your code.  So what.   Yes you may find
yourself building the same frameworks over and over again (e.g. to collect results
from an iteration) but as Kent pointed out when you read this code you recognize
common idioms like this simply from the structure.  In fact you can see what the code
is doing from the framework alone (the paren layout) without even reading what's
inside the parens.  

 Learn Lisp first.  Give it a chance before you start in on the loop language.

In your style-guide you furthermore advice against the usage of WHEN and
UNLESS with arguments that sound IMHO more plausible for Scheme then for
Common Lisp (IF, UNLESS and WHEN would be ambigous concepts)

For those that really want to avoid "unlispy syntax" I would recommend then
to avoid IF* and better use IF, WHEN and UNLESS appropriate and furthermore
use the ITERATE macro instead of the standard extended LOOP macro.

ciao,
Jochen

I think the key is to recognize when _not_ to use LOOP.
It is imho nicer to write e. g.

(dolist (i '(1 2 3))
  (print i))

than

(loop for i in '(1 2 3)
      do (print i))

or

(dotimes (x width)
  (dotimes (y height)
     (setf (aref *map* x y) (+ x y))))

instead of

(loop for x from 0 below width
      do (loop for y from 0 below height
               do (setf (aref *map* x y) (+ x y))))

If you don't need the special accumulation features (collect, nconcing,
append, maximize...) or the more declarative arithmetic FOR loop:

(loop for i from m to n by o ...)

then it is probably a better idea to use the other facilities.

ciao,
Jochen

I/O is quite complicated, yet not always "important" (in the sense of
wanting to be the visual focus).  Yet in Maclisp before FORMAT was common,
the use of
 (progn (terpri)
        (princ '|There |)
        (princ (cond ((= n 1) '|is|) (t '|are|)))
        (princ '| |)
        (let ((base 10)) (princ n))
        (princ '| |)
        (princ name)
        (cond ((not (= n 1)) (princ '|s|)))
        (princ '| here.|))
would completely dominate the landscape, making it hard to find the
computation.  We still fall back to this kind of thing once in a while, but
we gave up our general syntax in the common case to gain something very
valuable: conciseness and focus.

Likewise, for iteration, the business of generating, filtering, and
accumulating is very heavily idiomatic and to go and *implement* it every
time instead of to call up the idiom makes it necessary for people to
repeat sometimes-obscure incantations that they ought not to have to know
and that sometimes might even improperly optimize for a given implementation.
I agree it loses a little of the elegance you cite, but not irrationally.
There is a very definite gain to be had.

Yes if* has english language 'keywords' (then, else and elseif)
but unlike loop you don't have to read the keywords to know
what the code does.  They just exist to separate parts of
the conditional.

For example you can write  (if* aaaaaa  then   bbbbbb  else cccccc)
but you can't write (if* aaaaaa else cccccc then bbbbbb).
You know that after the predicate will be a 'then'.  You don't
even have to read it.   The 'else' is there just so you know
that cccccc doesn't follow bbbbbb which you don't see in
(if aaaaaa bbbbbb cccccc).
With loop you must read every keyword to understand what's going on.

Cheers,

(if aaaaaa then bbbbb elseif ccccc then ddddd else eeeee)

I have to read the keywords if I not indent the clauses appropriate (which
no bulk emacs will do right!)

But

(if aaaaa
     bbbbb
  (if ccccc
       ddddd
     eeeee))

is automaticall indented right by emacs

and even

(if aaaaa bbbbb (if ccccc ddddd eeeee))

is easier to glance at for me because the inner if is nested appropriately.

I see no real gain in doing it like IF* does - It did not happen very often
to me that I've written an IF were I really had to place an PROGN to
encapsulate the clauses. IMHO IF ic nicely indented by Emacs&Co. so that it
is pretty readable where the then and where the else clause is.

(if condition
    (then-clause ..)
  (else-clause ..))

against

(if* condition
  then
    (then-clause ..)
  else
    (else-clause ..))

Besides of the fact that it maks the code unnecessary longer it leads to
the problem that the clauses are indented on the same level. If the clauses
are a bit bigger than shown here the little else is visually vanishing
between.

Please see this as constructive critique - I'm telling you only of my
experience with e. g. IF* in general and besides that AllegroServe. I think
it is a good thing to get response - if it's positive or negative.

ciao,
Jochen

I'm not trying to join a debate on loop.  I just wanted to present the other side of
the intelligent people can then weigh the arguments on both sides.

I'm not suggesting that loop can be fixed either by adding parenthesis or coming up
with ways of indenting it to make it understandable.  It's a lost cause.

There is a point to be made about this though:

==== from kmp:

Yet in Maclisp before FORMAT was common,
the use of
 (progn (terpri)
        (princ '|There |)
        (princ (cond ((= n 1) '|is|) (t '|are|)))
        (princ '| |)
        (let ((base 10)) (princ n))
        (princ '| |)
        (princ name)
        (cond ((not (= n 1)) (princ '|s|)))
        (princ '| here.|))

==== end kmp

I believe that what you are saying is the format in Common Lisp introduced a new
language to save us from having to do I/O like above, and since that was a good thing
then maybe loop's introduction of a new language for iteration is a good thing as well
too.

Let's look at your example though.  It took you very little time to write that after
knowing what you wanted it to do, and I'm sure that everyone read it very quickly and
figured out what it did instantly.

Now I challenge everyone to write the equivalent using Format.   Time yourself to see
how long it takes.

<i'll pause here while you go do it>
..
..
..
..

Time's up..

here's my solution with a test case (i'm sure there are other ways of doing it)

(format t "There ~[are~;is~:;are~] ~:*~d ~a~2:*~p here." 1 'ball)

Can you read it and tell me without trying it whether it works or not?
Give it to a co-worker who hasn't seen this thread and ask him/her what it prints? How
long until you get an answer?

There's no question that the format string is more concise.   But is using it better?
Is writing code with the least number of characters always best or is it important to
write code that others can read and understand without reaching for the Lisp manual.

Another great example from kmp:

=== from kmp

For example, you might think
 (loop with i = (random 100) for x from 1 to 10 do (print (list i x)))
and
 (loop for  i = (random 100) for x from 1 to 10 do (print (list i x)))
meant the same in English, [but they don't do the same thing in loop]

=== end kmp

loop lulls you into thinking that you understand the program since you understand
English.   Make no mistake about it, loop is its own language.  If you use it you
condem everyone who reads the code to also learn the loop language.  

 Just as an example to the others about what we're talking about I took a code segment
out of AllegroServe wrapped in a defun for realism and I'll show you what it looks
like with if* (the foo function) and if (the bar function).
 One of the problems I have with the if special form occurs at the of the bar
function.  It's pretty easy to get confused and think that the dotimes at the end is
always executed.   At first glance you may not see the indentation difference between
the if and dotimes.   I've seen code where people put in comments like ";else" before
such a clause since they see the problem too.  All if* does is enforce that 'else'
comment (in effect).

(defun foo ()
  (if* text-mode
     then
          ; here is where we should do
          ; external format processing
          #+(and allegro (version>= 6 0 pre-final 1))
          (multiple-value-setq (buffer items tocopy)
            (octets-to-string
             mpbuffer
             :string buffer
             :start cur
             :end (+ cur tocopy)
             :string-start start
             :string-end (length buffer)
             :external-format external-format
             :truncate t))
          #-(and allegro (version>= 6 0 pre-final 1))
          (dotimes (i tocopy)
            (setf (aref buffer (+ start i))
              (code-char (aref mpbuffer (+ cur i)))))
     else
          (dotimes (i tocopy)
            (setf (aref buffer (+ start i))
              (aref mpbuffer (+ cur i))))))

(defun bar ()
  (if text-mode
      (progn
        ; here is where we should do
        ; external format processing
        #+(and allegro (version>= 6 0 pre-final 1))
        (multiple-value-setq (buffer items tocopy)
          (octets-to-string
           mpbuffer
           :string buffer
           :start cur
           :end (+ cur tocopy)
           :string-start start
           :string-end (length buffer)
           :external-format external-format
           :truncate t))
        #-(and allegro (version>= 6 0 pre-final 1))
        (dotimes (i tocopy)
          (setf (aref buffer (+ start i))
            (code-char (aref mpbuffer (+ cur i))))))

I agree that it's syntax is rather a different breed from the rest of
lisp... but one thing it shares with the language as a whole is the freedom
to abuse its features.  I've always thought loop gives you more rope than
you'll probably ever need, certainly more than enough to hang yourself!

As strictly "newbie" advice, I would say make sure your problem can't be
solved easily with mapcar, dotimes or dolist first, but if loop makes it
easier why hobble yourself?

Coby
--
(remove #\space "coby . beck @ opentechgroup . com")

Sorry, I couldn't resist. :)

Cheers

  (format t "There ~:[are~;is~] ~D ~A~P here." (= n 1) n name n)

I'm not advocating LOOP-only nor FORMAT-only.  I'm advocating that they
are well-placed in the language because they appeal to a large audience,
and I'm further arguing that that audience is not characterized by the
oversimplistic attribute "tasteless".  There are good and even tasteful
reasons  for using both of these.  Using LOOP and FORMAT certainly do
not uniquely define taste.  I'm not arguing that your desire to use
something else is tasteless.  I'm not arguing that there weren't aesthetic
trade-offs made.  But I think it goes a little far to say "avoid it like
the plague".

| John Foderaro <j...@unspamx.franz.com> writes:
...
| Is this a proposal that the correct fix to LOOP is a different way to
| parenthesize it?  If not, it seems like smokescreen.  If so, I'd be curious
| to see your proposed parenthesization.  I've found in my few tries that it's

Are you aware of Iterate
<http://www.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/lisp/code/...>?
(The distribution archive contains two Postscript documents (the
manual and "Don't Loop, Iterate" paper) that make good reading for
those unfamiliar with the package.)  I think it comes pretty close
to a nice "parenthesized LOOP".  Then again, I also think it is
even too close to a parenthesized LOOP in some ways.

| painful to do because some groupings either divide things that ought not be
| divided or don't divide things that ought.  e.g.,
|    for x from 3 to 5
| Should this be

IMO, there are two alternatives depending on how generic FOR you
want.  If you want a LOOP-like FOR that can assign to the given
variable numbers of some range, elements of a list, vector etc., I
think your example should be:

(for x (scan-range :from 3 :to 5))

The version for the elements of a list would be:

(for x (scan '(1 2 3)))

If you know Series, you should realize that what I just depicted is
FOR that assigns to its first argument elements of series given as
its second argument.  FWIW, I might have used shorter RANGE instead
of SCAN-RANGE if I didn't want to use existing scanners from the
Series package.  Also note that I'm not saying this is what I think
the full Series-FOR syntax should be; it is just what is needed to
handle your example.

If you don't want that generic FOR, then I think your example
should/could be:

(for x :from 3 :to 5)

While you _could_ make this kind of FOR at least as generic as
LOOP's FOR (obviously not as generic as the Series-FOR above,
though), I think it would be a bad idea.  A better idea would
probably be to have a separate form (actually, more than one form
might be needed) for iterating over the elements of different
containers.

| >  my advice: Avoid loop like the [plague].  Stick with all those parens.
|
| But what goes in them?  I posted several LOOP examples that I don't think
| were candidates for any hypothetical obfuscated-lisp award.  Perhaps you
| could go through those and post your preferred alternative.

I haven't read the whole thread but I'm sure those examples would
be handled nicely by Iterate.

                (if* (not (probe-file orig-dxl))
                   then (setq prev (rename-file dxl-file orig-dxl))
                 elseif (not (probe-file old-dxl))
                   then (setq prev (rename-file dxl-file old-dxl)))

    (defun bar ()
      (if something
          stuff-to-do-when-true
        stuff-to-do-when-false))

It seems to me that the blame here lies not with IF, but
with the peculiar convention, which I have never understood,
that indents the "then" and "else" parts of an IF differently.
It would almost make sense if the "else" part of an IF had an
implicit PROGN, but it doesn't.

With indentation more like

    (defun bar ()
      (if something
        stuff-to-do-when-true
        stuff-to-do-when-false))

it is much harder to miss the fact that the two consequent
clauses are indented by the same amount.

Perhaps someone can enlighten me. Why is IF so often indented
in this strange way? (Non-answer: "Because that's what emacs
lisp-mode does." So, why does emacs lisp-mode do it?)

In the particular case John Foderaro posted, the stuff-to-do-when-true
is moderately long (17 lines). If that's too long to be able to see
how the indentation lines up, well, that's a pity, but that sort of
issue arises absolutely all the time and there ought to be better
solutions than changing the syntax. Do we need a new syntax to
replace LET, with explicit end-of-scope markers? A new syntax for
function call, so you can't get confused about what function any
given thing is an argument to? That way lie XML and madness...

When you write something using FORMAT, it may be harder to
read. But, by being concise, it renders the surrounding code
easier to read. The code Kent cited is certainly easier to
check than John's version using FORMAT; but embed it, along
with a few similar fragments, into something else, and *the
whole of the something-else will become hard to read*. This
is a worthwhile trade-off only if the details of the output
are more important than the computation in which it's embedded.

Even if using obscure features of FORMAT is deemed evil,
it's possible to improve considerably on the fully explicit
code Kent posted by using FORMAT more simply.

    (format t "~&There ~A ~D ~A~A here."
              (if (= n 1) "is" "are")
              n name
              (if (= n 1) "" "s"))

Incidentally, John's code is not equivalent to Kent's; it's
missing an equivalent of the (TERPRI) at the start. I think
this is an indication that fully-written-out code is not as
much easier to read as one might think.