| | Sure. But what I was wondering was that if I insert my own | declaration, the macroexpanded code ends up with two different ones (CMU-CL's | one isn't removed) which looks weird. I was wondering if it's even legal.
CMUCL is doing something odd here. It has bound the loop counters to internally named variables, then inserted a (DECLARE UNSIGNED-BYTE #:Gxxxx) for each. Then, it let-binds those counters to the original variable names. So, your declaration on I and J do not conflict with the compiler inserted declarations. The more interesting thing here is that no matter what you declare for I and J, it will not effect the result type of the offset computation and the compiler will always generate a note. I'm pretty sure this is not what was intended. | > The compiler notes are about the computation for the actual element offset. | > The sum of two fixnums can be greater than the fixnum range. | | I'm not sure we understood each other: I understand why the compiler | issues the notes, but my question was about the fact that I have two nested | loops (one on I and one on J), but only notes about I. It's been a long time since I looked at that part of the compiler. Maybe Ray can comment. | | | | > If you constrain your SIZE variable to something less than 1/2 max fixnum | > then the notes will go away. | | Trying this: | | (defun assign (array value) | (declare (type (simple-array fixnum (* *)) array)) | (declare (type fixnum value)) | (let ((size (the (integer 0 100) (array-dimension array 0)))) | (dotimes (i size) | (dotimes (j size) | (setf (aref array i j) value))))) | | leads to the same notes about I (and still no note about J). Actually, I had inserted a contant as the counter limit, as in (dotimes (i 100) ...) and that caused the notes to go away. Constraining SIZE can't do it now, though it should. Paul
