Re: Is this right?

[Bill_Chiles@CHILES.SLISP.CS.CMU.EDU]

   * (setq bob 1)

   Warning: This variable is undefined:
     BOB

   1

This occurs because the interpreter uses an intermediate representation of
the compiler which has many advantages, but it does have some
disadvantages.  Basically, the interpreter is anal retentive about free
variables.  Some think this is helpful in the situation when you try to set
exported variables for some interface; the system will flame you if you
mistyped the name, and if it does not flame you, then you know you set the
variable and not a mistyping of it.  Some people think this is simply
annoying.  Those who like this property of the new system use DEFVAR
instead of SETF for the first setting of the variable.  Those who dislike
this annoyance use the following hack to squelch the messages:

   (defvar *stop-interpreter-silliness* t)

   (defun c::compiler-warning (format-string &rest format-args)
     (let* ((output (format nil "~?" format-string format-args))
	    (output-len (length output)))
       (declare (simple-string output))
       (unless (and c:*converting-for-interpreter*
		    *stop-interpreter-silliness*
		    (or (string= output "This variable is undefined:"
				 :end1 (min output-len 27))
			(string= output "These variables are undefined:"
				 :end1 (min output-len 30))))
	 (incf c::*compiler-warning-count*)
	 (c::print-error-message :warning format-string format-args))))

Note, this hack requires redefining a compiler internal routine.  Do so at
your own risk.

If enough users complain about this, we'll officially add a switch to turn
it off or make the compiler correctly squelch these warnings when
c:*converting-for-interpreter*.

Bill