Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!samsung!think!barmar
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.lang.lisp
Subject: Re: DEFVAR is forever
Message-ID: <33833@news.Think.COM>
Date: 9 Feb 90 06:37:08 GMT
References: <3277@accuvax.nwu.edu> <1990Jan28.175437.19293@hellgate.utah.edu> <1990Jan29.224305.20803@hellgate.utah.edu> <385@forsight.Jpl.Nasa.Gov> <1652@skye.ed.ac.uk> <ALMS.90Jan31142823@brazil.cambridge.apple.com>
Sender: news@Think.COM
Organization: Thinking Machines Corporation, Cambridge MA, USA
Lines: 39

In article <ALMS.90Jan31142823@brazil.cambridge.apple.com> alms@cambridge.apple.com (Andrew L. M. Shalit) writes:
>Turning off a special proclamation would involve going through all the
>compiled functions in the world which reference the variable, and
>changing them to treat the variable as lexical.

This is not necessary.  Just as DEFVAR doesn't find previous references to
the variable and change them from lexical to special, there's no need for
UNDEFVAR to go back and change them from special to lexical.  There's
precedent for this: (proclaim '(notinline <function-name>)) doesn't
de-inline previous invocations of the function.

Of course, since we're describing an implementation-dependent extension, we
can't really say for sure how it would behave.  If an implementation wanted
to provide the semantics you describe, and wanted to make it efficient, it
could keep back pointers.  However, I'm not sure why you'd want those
semantics.  Consider the following code:

(defvar *foobar*)

(defun fun1 (arg)
  (let ((*foobar* (* arg arg)))
    (fun2))

(defun fun2 ()
  (print *foobar*))

(undefvar *foobar*)

The point of the DEFVAR/UNDEFVAR is to make *FOOBAR* special only in the
functions FUN1 and FUN2; they're equivalent to wrapping all the functions
in a (locally (declare (special *foobar*)) ...).

In general, changing declarations should not affect previously-defined
functions.
--
Barry Margolin, Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar