[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: issue PROCLAIM-LEXICAL
- To: sandra <@cs.utah.edu:sandra@defun>, email@example.com
- Subject: Re: issue PROCLAIM-LEXICAL
- From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
- Date: Fri, 14 Oct 88 19:11:41 BST
- In-reply-to: sandra's message of Thu, 13 Oct 88 16:23:50 MDT
> I don't really like proposal LG very much. I gather from the discussion
> that there was also a proposal LDG around at one time?
I think the description in termas of LG, LDG, etc. can be confusing.
LDG is supposedly what happens to free references: look in L; if not
there, it's dynamic and that means DG. But variables declared special
are supposed to be just DG. But what if there's a lexical binding
in the way? Don't you have to look in L first? So perhaps that
case should be called LDG too.
I prefer a prepainting model: first paint all special variables
red. One of the rules for painting has free refs painted red.
Then they are just like variables declared special. In this
way, we separate the question "what's special?" from "how is
the value found?".
> This issue appears to be addressing what I consider to be actually
> two separate problems. The first problem is a way to undo SPECIAL
> declarations. Wasn't there once a proposal for an UNSPECIAL
> declaration to deal with this?
They can be separate. But they might not be. If there's a LEXICAL
proclamation for "global lexical" or "default to lexical and note that
this is a variable name that might occur free (so don't warn me about
it)", then the declaration that overrides a SPECIAL proclamation
should probably be LEXICAL too, rather than UNSPECIAL.
> The second problem is a way to specify a "global lexical variable".
> To me that implies something very much like what is specified for the
> binding behavior of DEFCONSTANT (it specifies a separate set of
> restrictions on SETQ'ing). I've thought for a long time that Common
> Lisp ought to provide a declaration for variable binding corresponding
> to what DEFCONSTANT does.
Now, that (i.e., CONSTANT proclamation) I think should be a separate
> Why not assign that meaning to the LEXICAL
> declaration, or maybe call it GLOBAL if people object to using
> LEXICAL? (The behavior of DEFCONSTANT is actually pretty close to
> what "GLOBAL" variables in PSL were like.) I suppose people would want
> an UNGLOBAL too....
There are some problems with the DEFCONSTANT model for "global lexical".
The constants are effectively proclaimed SPECIAL but (special) binding
is disallowed. Because of the SPECIAL proclamation, this prevents
lexical binding too; but lexical binding should not be prevented for
global lexicals. "Global" in Lisps like PSL means something like
"special but can't bind".
Another idea that comes out of Lisps that more or less had only dynamic
variables (and used deep binding) is that one wants to be able to get
the global value even if there are local (lexical) variables with the
same name in the way and perhaps even if there special bindings for that
name. In the current proposal, the way to get the global value is
either to call a function that refers free (so there's no lexical
shadowing) or to agree not to special bind that name and then use
(LOCALLY (DECLARE (SPECIAL V)) V). I think those are reasonable
solutions; whether the desire for something more is also reasonable is
That said, however, I don't think I disagree with you very much.
> The thing about proposal LG that strikes me as being the most
> confusing to users and troublesome to implementors is allowing access
> to both the dynamic and global value of the same variable. I think it
> would be reasonable to make the two mutually exclusive.
True, that would be a reasonable position to fall back to. But I would
prefer to think of it as lexical and special being mutually exclusive.
Either kind of variable might have a global value. But, as in a LET,
there can be only one kind of binding for a given name at a given level.
Global should be a "given level". You might think of this as saying
there are only two envs -- L and D -- and no separate G. In the
current "LG" proposal, it's best to think of it as having three envs:
L, D, and G. And if you think of it that way, the proposal makes