Re: Issue: PROCLAIM-LEXICAL

[Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>]

I'm sympathetic to the idea that undeclared free variables should
default lexical. Certainly if we had lexical globals I'd expect that
some compilers would start defaulting free variables lexical while
others would continue to default them special, so perhaps we should
just go ahead and make it well-defined.

Anyway, the separation of global lexical environment from global special
environment seems to me important. After all, you can already do:
 (DEFUN F (X) (+ X (LOCALLY (DECLARE (SPECIAL X)) X)))
and see two different variables X without any intervening rebinding.
I was just assuring that this effect was properly carried through.

Also, this assures that people cannot muck with the lexical binding
of any variable. Special variables are kind of 3lispy in nature because
we're told how they're represented and we have primitives for manipulating
them either as variables or as data. I think this makes program proofs
more difficult. The feature of lexical variables is that all of their
uses are statically detectable; this would not be so for global lexicals
if their homes were something that users were permitted to read in a 
non-statically-detectable way (eg, using SYMBOL-VALUE) or set (using SETF
of same). By making the lexical bindings totally isolated, you ensure
the right of the compiler to do much better compilation of global lexicals
in some cases than it might be able to do for global specials, and at the
same time you don't make any unpleasant changes to the mechanisms already
in place and in use for specials.

And finally, if you separate the two spaces, then you can go back and
forth between declaring variables special or not without it having strange
effect on things already compiled. eg, if you needed:

(DEFGLOBAL Y 3)
(DEFUN F (X) (+ X Y))
...
(PROCLAIM '(SPECIAL Y))
(DEFUN FOO (Y) (BAR))
(DEFUN BAR () ... (SETQ Y ...) ...)
(PROCLAIM '(LEXICAL Y))

without worrying that the global lexical Y=3 binding was in danger
of getting modified (which it seems intuitive to me that it should
not have been).

MACSYMA, for example, needs an UNSPECIAL declaration because on a
per-file basis it goes back and forth between using the same name either
special or lexical. Alternating back and forth between default LEXICAL
and default SPECIAL would serve it as well if we made that legal.
If such alternation meant that programs previously compiled using the
other semantics were now in error or might behave differently than I
intended at time-of-definition, then you've defeated the purpose of my
doing the alternation. I think the separation of namespaces ensures
intuitive behavior.