Is this defined common lisp or is the result undefined?
(LOOP FOR x FROM 1 TO 10
DO (SETF x (+ x 2))
COLLECT x)
Perusal of the hyperspec suggests that is in fact valid,
but I had always assumed it was not.
Thanks.
"Prabu" <·········@gmail.com> writes:
>> but I had always assumed it was not.
>
> WHY ?
Because the implementation might assume that it has control over
accumulation variables.
JP Massar wrote:
> Is this defined common lisp or is the result undefined?
>
> (LOOP FOR x FROM 1 TO 10
> DO (SETF x (+ x 2))
> COLLECT x)
>
> Perusal of the hyperspec suggests that is in fact valid,
> but I had always assumed it was not.
>
> Thanks.
Yes, I do it all the time! (Although maybe I shouldn't?)
········@gmail.com <········@gmail.com> wrote:
+---------------
| JP Massar wrote:
| > Is this defined common lisp or is the result undefined?
| > (LOOP FOR x FROM 1 TO 10
| > DO (SETF x (+ x 2))
| > COLLECT x)
| > Perusal of the hyperspec suggests that is in fact valid,
| > but I had always assumed it was not.
|
| Yes, I do it all the time! (Although maybe I shouldn't?)
+---------------
I personally consider it bad style, since it tends to hide from
the casual reader the actual sequence of values X takes. I usually
find that some other variation is more perspicuous, e.g., the
following yields the same result as the above:
(loop for x from 3 to 12 by 3
collect x)
Though I confess I *have* occasionally indulged in somewhat complex
BY clauses in LOOP, e.g., an example I posted a few weeks ago: ;-}
(flet ((stepper (list)
(case (car list)
((:one) (cddr list))
((:two) (cdddr list))
((:three) (cdddr list))
(otherwise (cdr list)))))
(loop for (key a b c) on list by #'stepper
...))
which can parse lists like this:
(:one 123 :two 234 453 :three 7 5 8 :special :other 99 22 :two 34 54)
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
According to 6.1.1.4 Expanding Loop Forms
(http://www.franz.com/support/documentation/8.0/ansicl/subsubse/expandin.htm),
the variable are "established in loop are bound as if by let or
lambda." As such, I see no reason why it would not be legal to modify
them with setf or similar.
-Jason
--
Posted via a free Usenet account from http://www.teranews.com
In article <··············@dev266-l.development.ravenpack.com>,
Jason S Cornez <·······@dev266-l.development.ravenpack.com> wrote:
> According to 6.1.1.4 Expanding Loop Forms
> (http://www.franz.com/support/documentation/8.0/ansicl/subsubse/expandin.htm),
> the variable are "established in loop are bound as if by let or
> lambda." As such, I see no reason why it would not be legal to modify
> them with setf or similar.
The issue isn't so much whether you can modify them, but whether this
has a predictable, portable effect on the iteration. E.g. if you do
(loop for i from 1 to 10
when (= i 5) do (setq i 8)
do (print i))
does this print 7 or 10 numbers? There might be a hidden variable
governing the actual iteration, and the user's iteration variable could
be assigned from the hidden variable at the beginning of each iteration,
e.g. it might expand into something equivalent to:
(do* ((hidden 1 (1+ hidden))
(i hidden hidden))
((> hidden 10))
(when (= i 5)
(setq i 8))
(print i))
The notion that the iteration is controlled with a hidden variable isn't
absurd. Iteration methods like FOR-IN are effectively *required* to use
a hidden variable, so a reasonable implementation might be modularized
to use one for everything.
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***