From Newsgroup: comp.lang.lisp

Geoff Wozniak wrote:

While doing the problems at Project Euler may not be considered work,
I can say that LOOP makes some of those puzzles easy to come up with reasonable answers. Something like

(loop for i from 1 to 1000 sum (expt i i))

sure is easy to type at the REPL.

I would take the time to learn the basics of LOOP, at the very least.

It's shorter when one uses a Lispy language instead of CL.

Gauche Scheme:

(use srfi-42) ;; sum-ec

(sum-ec (: i 1 1001) (expt i i))

Less condensed and probably faster:

(sum-ec (:range i 1 1001) (expt i i))


Paul Graham:

I consider Loop one of the worst flaws in CL, and an example
to be borne in mind by both macro writers and language designers.


[In "ANSI Common Lisp", Graham makes the following comments:]

The loop macro was originally designed to help inexperienced
Lisp users write iterative code. Instead of writing Lisp code,
you express your program in a form meant to resemble English,
and this is then translated into Lisp. Unfortunately, loop is
more like English than its designers ever intended: you can
use it in simple cases without quite understanding how it
works, but to understand it in the abstract is almost
impossible.
....
the ANSI standard does not really give a formal specification
of its behavior.
....
The first thing one notices about the loop macro is that it
has syntax. A loop expression contains not subexpressions but
clauses. The clauses are not delimited by parentheses;
instead, each kind has a distinct syntax. In that, loop
resembles traditional Algol-like languages. But the other
distinctive feature of loop, which makes it as unlike Algol as
Lisp, is that the order in which things happen is only
loosely related to the order in which the clauses occur.
....
For such reasons, the use of loop cannot be recommended.


Dan Weinreb, one of the designers of Common Lisp:

... the problem with LOOP was that it turned out to be hard to
predict what it would do, when you started using a lot of
different facets of LOOP all together. This is a serious problem
since the whole idea of LOOP was to let you use many facets
together; if you're not doing that, LOOP is overkill.


Barry Margolin:

My recommendation is based on seeing many question in the past
of the form "What happens if you use both XXX and YYY in the
same LOOP?" The unfortunate fact is that when we were writing
the standard we didn't have time to nail down all the possible
interactions between different LOOP features, so many of these
are not well specified. And even if we did get it right in
the standard, it's likely to be difficult to find them and I
wouldn't trust that all implementors got it right (many of
those questions were probably from implementors, trying to
figure out what they were supposed to do). And even if they
all got it right, someone reading your code may not be able to
figure it out.

So, with all those potential problems, my feeling is that if
you have to ask, it's probably better to use something other
than LOOP.


Barry Margolin:

3. Loop is very powerful, granted, and many people are trying to
argue that "you can do so much with loop that it's unreadable."
This is not an argument.

But it is! Because any use of LOOP has the potential to be
unreadable, the reader must read it carefully to verify that
it's just one of the cases that doesn't require careful
reading!


Barry Margolin (1997-01-08)

There are a few things that can be done extremely conveniently
with LOOP, and I will usually use LOOP in those cases. In
particular, the COLLECTING feature is one of the most
convenient.

The Generators and Collectors macros described in Appendix B
of CLtL2 also provide this convenience and are much more
Lisp-like. It's too bad they weren't around when LOOP was
gaining popularity, and I think they're a better way to go.
But LOOP is what I got used to, and its popularity is why it
got elevated into the ANSI standard.


Barry Margolin: (05 Apr 2002 20:57:48 GMT)

This seems like a big change just to clean up the way LOOP is described.
And LOOP will still be a wart, because it will be the only language feature that uses "per-macro keywords". Providing this interface and giving a name
to them would encourage other macro designers to do something similar, and
we don't want more things like LOOP.


John Foderaro:

I'm not trying to join a debate on loop. I just wanted to present
the other side of [the issue so that] 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.

...

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 condemn everyone who reads the
code to also learn the loop language.
--
[T]he problem is that lispniks are as cultish as any other devout group and basically fall down frothing at the mouth if they see [heterodoxy].
--- Kenny Tilton
The good news is, it's not Lisp that sucks, but Common Lisp. --- Paul Graham --- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.lisp

Geoff Wozniak wrote:

While doing the problems at Project Euler may not be considered work,
I can say that LOOP makes some of those puzzles easy to come up with reasonable answers. Something like

(loop for i from 1 to 1000 sum (expt i i))

sure is easy to type at the REPL.

I would take the time to learn the basics of LOOP, at the very least.

It's shorter when one uses a Lispy language instead of CL.

Gauche Scheme:

(use srfi-42) ;; sum-ec

(sum-ec (: i 1 1001) (expt i i))

Less condensed and probably faster:

(sum-ec (:range i 1 1001) (expt i i))


Paul Graham:

I consider Loop one of the worst flaws in CL, and an example
to be borne in mind by both macro writers and language designers.


[In "ANSI Common Lisp", Graham makes the following comments:]

The loop macro was originally designed to help inexperienced
Lisp users write iterative code. Instead of writing Lisp code,
you express your program in a form meant to resemble English,
and this is then translated into Lisp. Unfortunately, loop is
more like English than its designers ever intended: you can
use it in simple cases without quite understanding how it
works, but to understand it in the abstract is almost
impossible.
....
the ANSI standard does not really give a formal specification
of its behavior.
....
The first thing one notices about the loop macro is that it
has syntax. A loop expression contains not subexpressions but
clauses. The clauses are not delimited by parentheses;
instead, each kind has a distinct syntax. In that, loop
resembles traditional Algol-like languages. But the other
distinctive feature of loop, which makes it as unlike Algol as
Lisp, is that the order in which things happen is only
loosely related to the order in which the clauses occur.
....
For such reasons, the use of loop cannot be recommended.


Dan Weinreb, one of the designers of Common Lisp:

... the problem with LOOP was that it turned out to be hard to
predict what it would do, when you started using a lot of
different facets of LOOP all together. This is a serious problem
since the whole idea of LOOP was to let you use many facets
together; if you're not doing that, LOOP is overkill.


Barry Margolin:

My recommendation is based on seeing many question in the past
of the form "What happens if you use both XXX and YYY in the
same LOOP?" The unfortunate fact is that when we were writing
the standard we didn't have time to nail down all the possible
interactions between different LOOP features, so many of these
are not well specified. And even if we did get it right in
the standard, it's likely to be difficult to find them and I
wouldn't trust that all implementors got it right (many of
those questions were probably from implementors, trying to
figure out what they were supposed to do). And even if they
all got it right, someone reading your code may not be able to
figure it out.

So, with all those potential problems, my feeling is that if
you have to ask, it's probably better to use something other
than LOOP.


Barry Margolin:

3. Loop is very powerful, granted, and many people are trying to
argue that "you can do so much with loop that it's unreadable."
This is not an argument.

But it is! Because any use of LOOP has the potential to be
unreadable, the reader must read it carefully to verify that
it's just one of the cases that doesn't require careful
reading!


Barry Margolin (1997-01-08)

There are a few things that can be done extremely conveniently
with LOOP, and I will usually use LOOP in those cases. In
particular, the COLLECTING feature is one of the most
convenient.

The Generators and Collectors macros described in Appendix B
of CLtL2 also provide this convenience and are much more
Lisp-like. It's too bad they weren't around when LOOP was
gaining popularity, and I think they're a better way to go.
But LOOP is what I got used to, and its popularity is why it
got elevated into the ANSI standard.


Barry Margolin: (05 Apr 2002 20:57:48 GMT)

This seems like a big change just to clean up the way LOOP is described.
And LOOP will still be a wart, because it will be the only language feature that uses "per-macro keywords". Providing this interface and giving a name
to them would encourage other macro designers to do something similar, and
we don't want more things like LOOP.


John Foderaro:

I'm not trying to join a debate on loop. I just wanted to present
the other side of [the issue so that] 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.

...

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 condemn everyone who reads the
code to also learn the loop language.
--
[T]he problem is that lispniks are as cultish as any other devout group and basically fall down frothing at the mouth if they see [heterodoxy].
--- Kenny Tilton
The good news is, it's not Lisp that sucks, but Common Lisp. --- Paul Graham --- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.lisp

Kent M Pitman wrote:

(loop for x below 10 collect x)

Obviously and extremely unclear. What is the initial
value for x? Is it 1? Is it 0? Is it something else?

(loop for x in '(3 5 7)
for y in '(2 5 8)
when (= x y)
collect (cons x y))

Extremely unclear. Do we have two nested loops?
In the outermost loop, x iterates over the values
in the 1st list, and in the innermost loop, y
iterates over the values in the 2nd list.

Like this:

(do-ec (:list x '(3 5 7)) (:list y '(2 5 8))
(print (cons x y)))

(3 . 2)
(3 . 5)
(3 . 8)
(5 . 2)
(5 . 5)
(5 . 8)
(7 . 2)
(7 . 5)
(7 . 8)

If there is only 1 loop, then this is the way to do it.

(mapcan
(lambda(x y) (and (= x y) (cons x y)))
'(3 5 7) '(2 5 8))

===>
(5 . 5)

are examples of loops that are really quite clear and nothing to be seeking more complicated ways to say just to prove they can do it a more "lispy" way. To be "lispy" is NOT to "seek the obscure".

He finds Lispy code unclear; the only code that he finds clear
is COBOL-like code.

Look at the way he spells his name:

Kent M Pitman

He's telling us that his middle name is "M". To tell us that
the first letter of his middle name is "M", he would have
to say:

Kent M. Pitman

He may not even know what his middle name is.


Paul Graham:

I consider Loop one of the worst flaws in CL, and an example
to be borne in mind by both macro writers and language designers.


[In "ANSI Common Lisp", Graham makes the following comments:]

The loop macro was originally designed to help inexperienced
Lisp users write iterative code. Instead of writing Lisp code,
you express your program in a form meant to resemble English,
and this is then translated into Lisp. Unfortunately, loop is
more like English than its designers ever intended: you can
use it in simple cases without quite understanding how it
works, but to understand it in the abstract is almost
impossible.
....
the ANSI standard does not really give a formal specification
of its behavior.
....
The first thing one notices about the loop macro is that it
has syntax. A loop expression contains not subexpressions but
clauses. The clauses are not delimited by parentheses;
instead, each kind has a distinct syntax. In that, loop
resembles traditional Algol-like languages. But the other
distinctive feature of loop, which makes it as unlike Algol as
Lisp, is that the order in which things happen is only
loosely related to the order in which the clauses occur.
....
For such reasons, the use of loop cannot be recommended.


Dan Weinreb, one of the designers of Common Lisp:

... the problem with LOOP was that it turned out to be hard to
predict what it would do, when you started using a lot of
different facets of LOOP all together. This is a serious problem
since the whole idea of LOOP was to let you use many facets
together; if you're not doing that, LOOP is overkill.


Barry Margolin:

My recommendation is based on seeing many question in the past
of the form "What happens if you use both XXX and YYY in the
same LOOP?" The unfortunate fact is that when we were writing
the standard we didn't have time to nail down all the possible
interactions between different LOOP features, so many of these
are not well specified. And even if we did get it right in
the standard, it's likely to be difficult to find them and I
wouldn't trust that all implementors got it right (many of
those questions were probably from implementors, trying to
figure out what they were supposed to do). And even if they
all got it right, someone reading your code may not be able to
figure it out.

So, with all those potential problems, my feeling is that if
you have to ask, it's probably better to use something other
than LOOP.


Barry Margolin:

3. Loop is very powerful, granted, and many people are trying to
argue that "you can do so much with loop that it's unreadable."
This is not an argument.

But it is! Because any use of LOOP has the potential to be
unreadable, the reader must read it carefully to verify that
it's just one of the cases that doesn't require careful
reading!


Barry Margolin (1997-01-08)

There are a few things that can be done extremely conveniently
with LOOP, and I will usually use LOOP in those cases. In
particular, the COLLECTING feature is one of the most
convenient.

The Generators and Collectors macros described in Appendix B
of CLtL2 also provide this convenience and are much more
Lisp-like. It's too bad they weren't around when LOOP was
gaining popularity, and I think they're a better way to go.
But LOOP is what I got used to, and its popularity is why it
got elevated into the ANSI standard.


Barry Margolin: (05 Apr 2002 20:57:48 GMT)

This seems like a big change just to clean up the way LOOP is described.
And LOOP will still be a wart, because it will be the only language feature that uses "per-macro keywords". Providing this interface and giving a name
to them would encourage other macro designers to do something similar, and
we don't want more things like LOOP.


John Foderaro:

I'm not trying to join a debate on loop. I just wanted to present
the other side of [the issue so that] 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.

...

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 condemn everyone who reads the
code to also learn the loop language.
--
[T]he problem is that lispniks are as cultish as any other devout group and basically fall down frothing at the mouth if they see [heterodoxy].
--- Kenny Tilton
The good news is, it's not Lisp that sucks, but Common Lisp. --- Paul Graham --- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.lisp

"B. Pym" <Nobody447095@here-nor-there.org> writes:

(loop for x in '(3 5 7)
for y in '(2 5 8)
when (= x y)
collect (cons x y))

Because X and Y iterate over values that are independent,
the two rCyforrCO clauses can be joined by rCyandrCO, if that makes
it clearer for some:

(loop
for x in '(3 5 7) and y in '(2 5 8)
when (= x y)
collect (cons x y))

((5 . 5))

If there is only 1 loop, then this is the way to do it.

(mapcan
(lambda(x y) (and (= x y) (cons x y)))
'(3 5 7) '(2 5 8))

===>
(5 . 5)

That is almost correct. The solution should create a list
of dotted pairs. There is another problem, however. Add an
additional matching pair to the two sets:

(loop
for x in '(3 5 7 11 14) and y in '(2 5 8 11 18)
when (= x y)
collect (cons x y))

((5 . 5) (11 . 11))

(mapcan (lambda (x y) (and (= x y) (cons x y)))
'(3 5 7 11 14)
'(2 5 8 11 18))

(5 11 . 11)

But itrCOs easily fixed:

(mapcan (lambda (x y)
(when (= x y)
(list (cons x y))))
'(3 5 7 11 14)
'(2 5 8 11 18))

((5 . 5) (11 . 11))

The rCywhenrCO macro helps emphasize that rCymapcanrCO is being used
as a filter.
--
The lyf so short, the craft so long to lerne.
- Geoffrey Chaucer, The Parliament of Birds.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.lisp

B. Pym wrote:

Ken Tilton wrote:

Anyway, I whipped one up in a few lines that not only pulls n items
off the list, but it returns the remaining items as well. Let me know what you think. I was kind of surprised that I was able to do it without the use of an accumulator parameter.

(defun first-n (n list)
"Splits the list after the first n elements"
(if (= 0 n)
(values '() list)
(multiple-value-bind (from-front rest) (first-n (1- n) (rest
list))
(values (cons (first list) from-front) rest))))

I would probably do something like this instead:

(defun first-n (n list)
(loop for i below n for (a . d) on list
collect a into x
finally (return (values x d))))

Niiiiiiice.

Gauche Scheme:

We can make a solution shorter than the "loop" one
by using "!" (which is similar to "do" but is
optimized for brevity).

(define (first-n n List)
(! (i n -
r cons (car xs)
xs List cdr)
0 (values @ r xs)))

(first-n 2 '(a b c d e))

(a b)
(c d e)

Given:

(define-syntax !-aux
(syntax-rules (<> @ + - cons cdr :in :across :if ! )
[(_ (:if bool z ...) ((v i u) seen ...) stuff ...)
(!-aux (z ...)
((v i (if bool u v)) seen ...) stuff ...) ]
[(_ (x :in lst z ...) seen (lets ...) stuff ...)
(!-aux (x (and (pair? xs)(pop! xs)) <> z ...)
seen
(lets ... (xs lst)) stuff ...) ]
[(_ (x :across vec z ...) seen (lets ...) stuff ...)
(!-aux (x (and (< i (vector-length v))
(begin0 (vector-ref v i) (inc! i))) <>
z ...)
seen (lets ... (v vec) (i 0)) stuff ...) ]
[(_ (a b <> z ...) (seen ...) stuff ...)
(!-aux (z ...) (seen ... (a b b)) stuff ...) ]
[(_ (a b + z ...) (seen ...) stuff ...)
(!-aux (z ...) (seen ... (a b (+ 1 a))) stuff ...) ]
[(_ (a + n z ...) (seen ...) stuff ...)
(!-aux (z ...) (seen ... (a 0 (+ n a))) stuff ...) ]
[(_ (a b - z ...) (seen ...) stuff ...)
(!-aux (z ...) (seen ... (a b (- a 1))) stuff ...) ]
[(_ (a cons b z ...) (seen ...) stuff ...)
(!-aux (z ...) (seen ... (a '() (cons b a))) stuff ...) ]
[(_ (a b cdr z ...) (seen ...) stuff ...)
(!-aux (z ...) (seen ... (a b (cdr a))) stuff ...) ]
[(_ (a b c z ...) (seen ...) stuff ...)
(!-aux (z ...) (seen ... (a b c)) stuff ...) ]
[(_ (a b) (seen ...) stuff ...)
(!-aux () (seen ... (a b)) stuff ...) ]
[(_ (a) (seen ...) stuff ...)
(!-aux () (seen ... (a '())) stuff ...) ]
;;
[(_ () seen lets a b c ! action ...)
(!-aux () seen lets (a b c) #t (action ...)) ]
[(_ () seen lets a b ! action ...)
(!-aux () seen lets (a b) #t (action ...)) ]
[(_ () seen lets a ! action ...)
(!-aux () seen lets a #t (action ...)) ]
;;
[(_ () ((a b c) z ...) lets bool)
(!-aux () ((a b c) z ...) lets bool a) ]
[(_ () ((a b c) z ...) lets bool @)
(!-aux () ((a b c) z ...) lets bool (reverse a)) ]
[(_ () seen lets bool @ result stuff ...)
(!-aux () seen lets bool (reverse result) stuff ...) ]
[(_ () seen lets bool (what @ x z ...) stuff ...)
(!-aux () seen lets bool (what (reverse x) z ...) stuff ...) ]
[(_ () seen lets bool (what x @ y z ...) stuff ...)
(!-aux () seen lets bool (what x (reverse y) z ...) stuff ...) ]
[(_ () ((a b c) z ...) lets 0 stuff ...)
(!-aux () ((a b c) z ...) lets (= 0 a) stuff ...) ]
[(_ () seen lets bool result stuff ...)
(let lets (do seen (bool result) stuff ...)) ]
))
(define-syntax !
(syntax-rules ()
[(_ specs bool stuff ...)
(!-aux specs () () bool stuff ...) ]
))
--
[T]he problem is that lispniks are as cultish as any other devout group and basically fall down frothing at the mouth if they see [heterodoxy].
--- Kenny Tilton
The good news is, it's not Lisp that sucks, but Common Lisp. --- Paul Graham --- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.lisp

(loop for x in '(3 5 7)
for y in '(2 5 8)
when (= x y)
collect (cons x y))

What if there were more than two lists?
This will handle any number of lists:

Scheme:

(filter-map
(lambda xs (and (apply = xs) xs))
'(0 3 5 7 9)
'(0 2 5.0 8 9.0)
'(2 4 5 8 9))

((5 5.0 5) (9 9.0 9))
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.lisp

On 2025-06-19, B. Pym <Nobody447095@here-nor-there.org> wrote:

(loop for x in '(3 5 7)
for y in '(2 5 8)
when (= x y)
collect (cons x y))

What if there were more than two lists?
This will handle any number of lists:

Scheme:

(filter-map
(lambda xs (and (apply = xs) xs))

What's wrong with (if (apply = xs) xs)?

'(0 3 5 7 9)
'(0 2 5.0 8 9.0)
'(2 4 5 8 9))

((5 5.0 5) (9 9.0 9))

This is nicer:

(mappend [iff = [chain list list]]

'(0 3 5 7 9)
'(0 2 5.0 8 9.0)
'(2 4 5 8 9))
((5 5.0 5) (9 9.0 9))
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.lisp

Kaz Kylheku <643-408-1753@kylheku.com> writes:

> Scheme:
>
> (filter-map
> (lambda xs (and (apply = xs) xs))

What's wrong with (if (apply = xs) xs)?

In Scheme, (if #F whatever) is undefined, while (and #F whatever) is #F.

At least that's the way it was in R5RS. I don't have a more recent
version of the specification handy.

(Meanwhile in Common Lisp, (if nil whatever) is nil.)

(Kaz: Why are you wasting your time replying to this junk?)
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.lisp

On Thu, 19 Jun 2025 19:22:49 -0400, Alan Bawden wrote:

At least that's the way it was in R5RS. I don't have a more recent
version of the specification handy.

<http://www.r6rs.org/>
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.lang.lisp

Ken Tilton wrote:

Anyway, I whipped one up in a few lines that not only pulls n items
off the list, but it returns the remaining items as well. Let me know >>what you think. I was kind of surprised that I was able to do it
without the use of an accumulator parameter.

(defun first-n (n list)
"Splits the list after the first n elements"
(if (= 0 n)
(values '() list)
(multiple-value-bind (from-front rest) (first-n (1- n) (rest
list))
(values (cons (first list) from-front) rest))))

I would probably do something like this instead:

(defun first-n (n list)
(loop for i below n for (a . d) on list
collect a into x
finally (return (values x d))))

Niiiiiiice.

Gauche Scheme:

(define (first-n n xs . ys)
(dotimes (n) (push! ys (pop! xs)))
(values (reverse ys) xs))
--- Synchronet 3.21d-Linux NewsLink 1.2