From: <don...@is...> - 2010-10-11 20:43:54
|
In cvs head I notice the following warning which I think is wrong. (COMPILE 'AP-COMPILED::F1301 '(LAMBDA (|GenFn| X2 X3 X4 &AUX |GenFun | |Exhausted | X5 X6) X2 X3 X4 (SETQ |GenFun | (FUNCALL |GenFn| X4 X2 X3)) (LOOP UNTIL (MULTIPLE-VALUE-SETQ (|Exhausted | X5 X6) (FUNCALL |GenFun |)) COLLECT (LIST X3 X2 X4 X5 X6)))) WARNING: in AP-COMPILED::F1301 : variable |Exhausted | is assigned but not read The next latest version I have already built and stored on disk is Jul 16, 2.49 without the + and there I get no warning. |
From: Sam S. <sd...@gn...> - 2010-10-11 21:17:41
|
Don Cohen wrote: > In cvs head I notice the following warning which I think is wrong. > (COMPILE 'AP-COMPILED::F1301 > '(LAMBDA (|GenFn| X2 X3 X4 &AUX |GenFun | |Exhausted | X5 X6) X2 X3 X4 > (SETQ |GenFun | (FUNCALL |GenFn| X4 X2 X3)) > (LOOP UNTIL (MULTIPLE-VALUE-SETQ (|Exhausted | X5 X6) (FUNCALL |GenFun |)) > COLLECT (LIST X3 X2 X4 X5 X6)))) > WARNING: in AP-COMPILED::F1301 : variable |Exhausted | is assigned but > not read indeed, |Exhausted | is assigned a value by MULTIPLE-VALUE-SETQ but that value is never accessed. you need to declare it IGNORABLE to avoid this warning. note that the value stored in |Exhausted | is indeed used by the LOOP UNTIL clause, but that values comes from evaluating (FUNCALL ..), not from the variable, so there is not reason to store a value in |Exhausted |. |
From: <don...@is...> - 2010-10-11 23:58:26
|
Sam Steingold writes: > note that the value stored in |Exhausted | is > indeed used by the LOOP UNTIL clause, but that values comes from > evaluating (FUNCALL ..), not from the variable, so there is not > reason to store a value in |Exhausted |. So you consider this to be a bug fix. It's sort of strange that in cases like this you are required to invent a variable name and then declare it ignorable. But I see, in trying to get rid of the warnings that allegro must also warn in these cases. |
From: <don...@is...> - 2010-10-15 06:26:54
|
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. 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? But in the loop it's only written? Are loop variables processed differently from let variables? Is it really the case that there is no way to declare loop variables ignorable? (I know that's not really a clisp issue.) 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) 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. |
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/ |
From: <don...@is...> - 2010-10-15 19:54:30
|
> You realize that the reference to b in the progn is dead code. So it's > eliminated, So b is not referenced anymore. Yes, but it used to at least be a useful way to avoid the warnings. > 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? In all of the cases involved there was no typo. I ended up rewriting things like (loop for x in a collect 'input) to (loop for x below (length a) collect 'input) I still have code like (loop for (x y z) in a collect y) I really don't like to use nil there but I could. > > 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... such that in general (loop for [variable list] s.t. [well formed formula] ...) see ap5.com for more detail |
From: Sam S. <sd...@gn...> - 2010-10-15 20:13:21
|
Don Cohen wrote: > (loop for (x y z) in a collect y) > I really don't like to use nil there but I could. we could add (declare ignore) for all variables starting with an underscore (like in ocaml). then you will be able to write (loop for (_x y _z) in a collect y) and see no warnings. if you like the idea, please discuss it on c.l.l. |
From: <don...@is...> - 2010-10-17 05:37:21
|
Sam Steingold writes: > Don Cohen wrote: > > (loop for (x y z) in a collect y) > > I really don't like to use nil there but I could. > > we could add (declare ignore) for all variables starting with an underscore > (like in ocaml). > then you will be able to write > (loop for (_x y _z) in a collect y) > and see no warnings. > > if you like the idea, please discuss it on c.l.l. That proposal does not appeal to me. After thinking about it, I suggest that the compiler at least provide some control (which behavior us the default is another matter) over whether the mention of a variable, even if it can/will be optimized out, is considered a "use" for purposes of warning about variables being unused (inc. not read). The main reason for doing this is that a lot of older code (though less of mine than a few days ago) makes use of that convention. |
From: <pj...@in...> - 2010-10-15 20:24:52
|
don...@is... (Don Cohen) writes: > > You realize that the reference to b in the progn is dead code. So it's > > eliminated, So b is not referenced anymore. > Yes, but it used to at least be a useful way to avoid the warnings. > > > 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? > In all of the cases involved there was no typo. > I ended up rewriting things like > (loop for x in a collect 'input) > to > (loop for x below (length a) collect 'input) > I still have code like > (loop for (x y z) in a collect y) > I really don't like to use nil there but I could. > > > > 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... > such that > in general > (loop for [variable list] s.t. [well formed formula] ...) > see ap5.com for more detail Ok. Well, without looking at the source of the implementation of s.t. it should be noted that in general loops may provide the variables as a new binding in each loop iteration, in which case even if you use it in the wff, the one you get in the body will be a new binding, and this is probably that one that is not used. In this case indeed, you cannot use nil, so you must use the variable. Perhaps like this: (loop for (a b) s.t. (r a b) collect (let ((b b)) (declare (ignore b)) a)) -- __Pascal Bourguignon__ http://www.informatimago.com/ |