• re: lush, variable scope, iteration

    From B. Pym@Nobody447095@here-nor-there.org to comp.lang.lisp on Thu Jul 17 04:19:06 2025
    From Newsgroup: comp.lang.lisp

    Christopher C. Stacy wrote:

    This is why it's better to write it like this:

    (loop for i from 1 to 3 do ....)
    or (loop repeat 3 do ...) ;no variable needed.
    or (loop for i below 4 do (print x))

    and not return the iteration control variable's value.

    Those are all just the most trivial examples of LOOP.
    LOOP has many other powerful features.

    LOOP was a controversial addition to the standard.
    Half the community hates it, while the others ranges from
    pragmatic acceptance to really liking it. The main issue
    is aesthetic. As you can see, LOOP introduces its own
    ("non-Lispy") language syntax. And it's possible to write
    incomprehensible LOOP code by combining the features in
    various ways. Usually people write LOOP code that makes
    the iteration very clear and concise.


    Did he make the iteration very clear?
    Do we know what he is doing?
    Does he know what he's doing?

    Testing:

    * (loop for i from 1 to 3 do (print (list i)))

    (1)
    (2)
    (3)

    * (loop for i below 4 do (print (list i)))

    (0)
    (1)
    (2)
    (3)

    The answer to every question is "No."


    Common Lisp has a lot of other iteration primitives built-in.
    These predate LOOP, and are plain good Lisp syntax.
    Besides your basic goto (GO), there's the powerful and
    venerable DO macro (unrelated to the "DO" clasuse in LOOP).
    some people find DO a little difficult to read.

    (do ((i 1 (incf i)))
    ((> i 3) i)
    (print i))

    Horrible. It ought to be:

    (do ((i 1 (1+ i)))
    ((> i 3) i)
    (print i))

    He doesn't even understand the simple "do" macro.


    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 (05 Dec 2004)
    --- Synchronet 3.21a-Linux NewsLink 1.2