[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Another omission: global lexicals
- To: RAM@C.CS.CMU.EDU, DLW@SCRC-QUABBIN.ARPA
- Subject: Another omission: global lexicals
- From: Guy Steele <gls@THINK-AQUINAS.ARPA>
- Date: Mon, 16 Dec 85 13:14 EST
- Cc: common-lisp@SU-AI.ARPA, gls@THINK-AQUINAS.ARPA
- In-reply-to: <RAM.12167410294.BABYL@C.CS.CMU.EDU>
Date: Sun, 15 Dec 1985 18:40 EST
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
Yes, we seem to be talking about the same thing. I believe you
have the right model for interaction with specials: there is none.
Unfortunately this means that shallow-binding implementations would
have to have separate lexical and special value cells, since you could
do something like this:
(defglobal foo :global)
(let ((foo :special))
(declare (special foo))
(defun bar ()
(format t "~S or ~S, take you pick."
foo (locally (declare (special foo)) foo)))
This doesn't mean that your symbol needs another slot though. You
could keep the lexical value cells somewhere else (such as on the
PLIST!!), since you only need to locate the value cell at load time.
I think it is a bad idea to let "global lexicals" and specials be completely
independent, for the simple reason that in
(defvar foo 3)
(defun baz () foo)
(baz) => 3
(defglobal foo 5)
(baz) => 5
the DEFGLOBAL changes the meaning of the variable reference in BAZ.
Right now the meaning of FOO within BAZ can be determined by inspection
of only BAZ: because there is no *lexically apparent* lexical binding,
the reference to FOO must be special. With DEFGLOBAL as proposed, the
meaning of FOO cannot be understood out of context.
Here is a different model for DEFGLOBAL: it is just like DEFCONSTANT
except you are allowed to SETQ it. So you can change its value with a
side effect (or even make it unbound), but it is an error to bind it.