Paul Werkowski wrote: > | > | 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.
If you're using a recent snapshot, then, yes, that happens. I changed the dotimes macro some time ago because of a discussion on this list about what should happen in (dotimes (k n) <modify k>). It was decided that the loop should still run n times, but the value of k would be as modified. I think to get this right, you'd have to parse any declarations for the loop counter and apply that to the gensym'ed loop counter. I didn't do that. As to why there are no notes for the j loop, I don't know. Perhaps the heuristics used for generating notes fail in this case. Perhaps confused by the gensym'ed loop counter? Ray
