[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
annoying compiler warnings again
- Subject: annoying compiler warnings again
- From: kab (Kim Barrett)
- Date: Tue, 15 Jun 93 17:06:05
> Is there some way to keep the
> TIME macro from complaining about undeclared free variables in a top-level
> ? (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 ...
> 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
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.