|
| 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
|