Issue: SPECIAL-VARIABLE-TEST (Version 1)

[Kent M Pitman <KMP@STONY-BROOK.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
concurred.