|
From: <pj...@in...> - 2010-10-15 15:55:49
|
don...@is... (Don Cohen) writes:
> In 2.49 the following gives no warnings, in cvs it shows the two below.
> (compile nil (lambda (x)(loop for (a b c) in x collect (progn b a))))
> WARNING: variable B is assigned but not read
> WARNING: variable C is assigned but not read
>
> I had expected the warning about c but not b.
You realize that the reference to b in the progn is dead code. So it's
eliminated, So b is not referenced anymore.
> It used to be that one could just mention a variable to avoid a
> warning about it not being used. It seems somewhat annoying to
> lose that.
>
> I notice in both versions
> (compile nil (lambda ()(let (a b c) (progn b a))))
> WARNING: variable C is not used.
> Misspelled or missing IGNORE declaration?
>
> I'm having a little trouble making sense of this.
> In the let b is read and written?
No, same reason as above. I would write it as:
(compile nil (lambda ()
(let (a b c)
(declare (ignorable b) (ignore c0))
(progn b a))))
> But in the loop it's only written?
> Are loop variables processed differently from let variables?
Unfortunately, in loop, there's no place for declarations about loop's
variables. The loop macro itself could have an ignorable declaration
for them but I don't remember if that would be conformant, and it would
be questionnable anyways: the warning is good: did you really not make a
typo?
If you don't need the variable, you can use NIL instead, thanks to:
Macro LOOP
d-var-spec::= simple-var | nil | (d-var-spec . d-var-spec)
6.1.2.1 Iteration Control
The variable argument in iteration control clauses can be a
destructuring list. A destructuring list is a tree whose non-nil atoms
are variable names. See Section 6.1.1.7 (Destructuring).
6.1.1.7 Destructuring
If nil is used in a destructuring list, no variable is provided for its place.
So:
CL-USER> (compile nil (lambda (x)(loop for (a nil nil) in x collect (progn a))))
#<COMPILED-FUNCTION NIL>
NIL
NIL
> Is it really the case that there is no way to declare loop variables
> ignorable? (I know that's not really a clisp issue.)
Yes. You should avoid introducing them using nil instead.
> I was even getting "not read" warnings from my loop extension in
> cases like this
> (loop for (a b) s.t. (r a b) collect a)
Too bad you don't say what s.t. is...
> where I really am using b and certainly cannot replace it with nil.
> I ended up changing the macro expander to declare both a and b
> ignorable.
>
--
__Pascal Bourguignon__ http://www.informatimago.com/
|