annoying compiler warnings again

[kab (Kim Barrett)]

> Is there some way to keep the
> TIME macro from complaining about undeclared free variables in a top-level
> expression?
>
> example:
> ? (setq test-text "Blah, blah, blah.")
> "Blah, blah, blah."
> ? (char test-text 0)
> #\B           ;;; great.  No compiler warnings, but...
> ? (time (char test-text 0))
> ;Compiler warnings :
> ;   Undeclared free variable TEST-TEXT, in an anonymous lambda form.
> (CHAR TEST-TEXT 0) took ...
> T
> 
> I can, of course, get around this with some verbose thing like
>    (time (LET () (DECLARE (SPECIAL TEST-TEXT)) (char test-text 0)))
> but this is gross to type when your just testing manually.
> How about if MCL locally binds some compiler parameter around the form in the
> macroexpansion of TIME to prohibit undeclared-free-variable warnings?

There is no direct relationship between the warnings and TIME.  The reason you 
sometimes get warnings and sometimes don't is that the listener runs a 
read-eval-print loop that looks at the form and executes it directly if it is 
sufficiently "simple" (where simplicity is determined by which forms the MCL 
developers have bothered to provide implementations for in this little 
interpreter), and otherwise compiles the form and calls the resulting function.  
The idea is that MCL is a compiled-only implementation (*) but as an 
optimization the listener avoids the overhead involved in invoking the compiler 
for sufficiently trivial forms.

The problem with that approach is that the toy interpreter differs from the 
compiler in how picky it is about things like undeclared free variable 
references.

The solution I've adopted is to stop using SETQ for assigning interesting values 
to variables in the listener, and instead use DEFPARAMETER for that purpose. 
(Actually, I use a macro with a shorter name that expands into DEFPARAMETER).

(*) At least by default.  There's some (documented) flag that I never use that 
makes it use an interpreter.  I used it a few times long ago so that I could use 
the STEP macro, but I found that to be rather clumsy and other debugging tools 
sufficient and have ended up not using it anymore.

> This is annoying because, among other things, it switches me
> to the listener window from whatever buffer holds the TIME form, and makes
> me have to read the error message and figure out why it should be ignored.

For those of you who, like me, despise the current MCL behavior of forcing the 
Listener to the front when a warning is reported, putting the following little 
dance in your init file works pretty well.

(setf *error-output* *terminal-io*)         ;warnings don't pop up
(setf *debug-io* ccl::*pop-up-terminal-io*) ;debugger pops up

I can't vouch for the longevity of *pop-up-terminal-io* though, so this might 
stop working in some future release.