assignment to iteration control variables in loop?
Bulent Murtezaoglu
I have spent some time reading the Hyperspec section 6.1 but was unable to
find whether assignment to iteration control variables in the body is
allowed. That is, say in
(loop for i from 1 to 10 do <something>)
can <something> setf i?
I don't want to do this, I just want to see if the loop macro can
legally infer the type (and thus insert a declaration) (integer 1 10)
from that for clause.
Is there verbiage that proscribes assignment to these variables (like
there is for object traversing)?
thanks,
BM
Kent M Pitman
> I have spent some time reading the Hyperspec section 6.1 but was unable to
> find whether assignment to iteration control variables in the body is
> allowed. That is, say in
>
> (loop for i from 1 to 10 do <something>)
>
> can <something> setf i?
I agree the spec doesn't say and I have generally recommended that this
means no, you can't. Nothing guarantees to you that the successive
assignments are being taken from prior values of i.
> I don't want to do this, I just want to see if the loop macro can
> legally infer the type (and thus insert a declaration) (integer 1 10)
> from that for clause.
This is a different question. The prior question is "may an implementation
prevent you from doing (setq i ...)?"; this one is "must a user not do
(setq i ...)?", and I'm not sure.
Gray areas in the spec are odd: I recommend for safety that users not
use features that an implementation might not provide; but I recommend
for safety that implementations assume that users ARE using those
features. Worst of all possible worlds, since it suggests doing work
that no one uses.... Sigh.
> Is there verbiage that proscribes assignment to these variables (like
> there is for object traversing)?
This question has come up before, and my recollection is that the answer is:
No.
But I didn't check this time.
Erik Naggum
| I have spent some time reading the Hyperspec section 6.1 but was unable
| to find whether assignment to iteration control variables in the body is
| allowed.
More important than "allowed", what would you want it to mean? Is an
assignment likely to have only one possible meaning or multiple? If the
latter, common sense dictates that you do not use such assignment. If
you assume that it has only one possible meaning, this can be refuted by
experiment with existing implementations.
| I don't want to do this, I just want to see if the loop macro can
| legally infer the type (and thus insert a declaration) (integer 1 10)
| from that for clause.
That certainly seems warranted _unless_ some form in the body of the loop
assigns to the variable. If the variable binding is special, I think it
is unwarranted to make any sort of declaration.
| Is there verbiage that proscribes assignment to these variables (like
| there is for object traversing)?
Not that I know of.
///
--
In a fight against something, the fight has value, victory has none.
In a fight for something, the fight is a loss, victory merely relief.
lin8080
...
> (loop for i from 1 to 10 do <something>)
> can <something> setf i?
...
From: ... HyperSpec/Body/mac_docm_dost.html
Macro DO, DO*
Syntax:
do ({var | (var [init-form [step-form]])}*) (end-test-form result-form*)
declaration* {tag | statement}*
=> result*
do* ({var | (var [init-form [step-form]])}*) (end-test-form
result-form*) declaration* {tag | statement}*
=> result*
Arguments and Values:
var---a symbol.
init-form---a form.
step-form---a form.
end-test-form---a form.
result-forms---an implicit progn.
declaration---a declare expression; not evaluated.
tag---a go tag; not evaluated.
statement---a compound form; evaluated as described below.
results---if a return or return-from form is executed, the values passed
from that form; otherwise, the values returned by the result-forms.
Description:...
hope it helps
stefan