[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: SPECIAL-VARIABLE-TEST (Version 1)
- To: Moon@STONY-BROOK.SCRC.Symbolics.COM
- Subject: Issue: SPECIAL-VARIABLE-TEST (Version 1)
- From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Mon, 7 Mar 88 15:32 EST
- Cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.STANFORD.EDU
- In-reply-to: <19880307185953.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 7 Mar 88 13:59 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
... why isn't the proposal named SPECIAL-VARIABLE-TEST:SPECIAL-VARIABLE-P ...
Editing error. I changed the name from SPECIALP to SPECIAL-VARIABLE-P
while evolving the proposal and didn't make the change completely enough.
For clarity, someone should change it in the next draft.
For the current practice section: Symbolics Genera has a function
named SYS:SPECIAL-VARIABLE-P that does this. The function is not
documented, currently, probably because we've been waiting to see
if Common Lisp standardizes on a different name.
After looking at our SYS:SPECIAL-VARIABLE-P, I note a possible oversight
in this proposal. With Common Lisp, as opposed to Zetalisp, scoping
rules for SPECIAL declarations, there are two distinct questions one can
ask about the declaration of a variable. One is, "would a reference to
this variable in this environment be special?". The second is, "would a
binding of this variable in this environment be special?". The proposal
only answers the first question.
The second question is a little harder because you need to figure out
how to feed local declarations attached to the binding to the predicate.
I suggest a very simple solution: to ask the second question, one
supplies NIL as the environment, which accesses the proclamations
without the declarations, and then one handles manually any local
declarations attached to the binding. This is minimalist but should
do the job. The proposal doesn't need any technical changes for this,
but should include a brief mention of this issue and the solution.
This sounds mostly ok, though we'd need to be clear about which of these
an appropriate type-2 call to SPECIAL-VARIABLE-P looked like:
1. (SPECIAL-VARIABLE-P 'FOO '((DECLARE (SPECIAL X) (FIXNUM X))
(DECLARE (SPECIAL Y))))
2. (SPECIAL-VARIABLE-P 'FOO '(DECLARE (SPECIAL X) (FIXNUM X) (SPECIAL Y)))
3. (SPECIAL-VARIABLE-P 'FOO '(((SPECIAL X) (FIXNUM X)) ((SPECIAL Y))))
4. (SPECIAL-VARIABLE-P 'FOO '((SPECIAL X) (FIXNUM X) (SPECIAL Y)))
5. (SPECIAL-VARIABLE-P 'FOO '(X Y))
1, 4, and 5 look ok to me. 1 seems like it would be easiest to arrange
for in practice, and hence perhaps the best choice.
I note also that this only works because special bindings are not
pervasive. If they were not, you'd have to have the environment argument
also. In philosophy courses I've taken, we'd say it is "true" that the
environment is not needed, but it is not "necessarily true" (i.e., there
exist consistent, possible universes in which it is not true). For
implementational flexibility in case anyone -wants- pervasive bindings
(as an, arguably incompatible, extension) or in case we later want to
change the language, it might be cleaner to say
(SPECIAL-VARIABLE-P 'FOO ENV '(...decls...))
and to mention to implementors that in fact the ENV may be ignored if the
decls are passed. It's especially interesting in the case of
(SPECIAL-VARIABLE-P 'FOO NIL) ;null environment
vs (SPECIAL-VARIABLE-P 'FOO '()) ;no decls
because these both do the same thing but for completely different reasons.
It really stretches the pun to unreasonable lengths. I'd be content to
rewrite the proposal to accomodate this additional issue if others