CL-USER> (load (compile-file "test.lisp")) T
Seems the actual problem is that you didn't cut-n-paste my code. It gives no warnings on cmucl or sbcl. Michael On 1/9/06, Jason F Kantz <[EMAIL PROTECTED]> wrote: > > > > On 1/9/06, Jason F Kantz <[EMAIL PROTECTED]> wrote: > >> Here's an example of my problem: > >> > >> (defun test (a b) > >> (declare (optimize (speed 3)) > >> (type fixnum a) > >> (type fixnum b)) > >> (loop for x from a to b > >> do (print (* x x)))) > >> > >> Is there a way to use loop without losing on type declarations like > >> this? > > > > (defun test (a b) > > (declare (optimize (speed 3) (safety 0) (debug 0)) > > (type fixnum a) > > (type fixnum b)) > > (loop for x fixnum from a to b > > do (print (the fixnum (* x x))))) > > The problem actually lies with the counting code created by the loop > macro. Macro expanding the loop form gives ... > > (BLOCK NIL > (LET ((X A) (#:G3669 B)) > (DECLARE (TYPE NUMBER #:G3669) (TYPE NUMBER X)) > (ANSI-LOOP::LOOP-BODY NIL > (NIL NIL > (WHEN (> X #:G3669) (GO ANSI-LOOP::END-LOOP)) > -- snip -- > > so it seems like these number declarations interfere with the type > inferencing that should be taking place. I get several notes concerning > the counting variable in the loop body. One of which is > > ; (LOOP FOR X FROM A ...) > ; --> BLOCK LET ANSI-LOOP::LOOP-BODY TAGBODY WHEN COND IF > ; ==> > ; (> X #:G0) > ; Note: Unable to optimize due to type uncertainty: > ; The first argument is a REAL, not a FLOAT. > >
