Poor excuse for packages

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

    Date: Friday, 17 May 1985, 10:32-EDT
    From: Guy Steele <gls%AQUINAS@THINK.ARPA>

    KMP hinted at a very interesting solution to the special-variables
    problem: let symbols in the package SPECIAL name special variables,
    and let all others name local variables.  There doesn't seem to be
    much wrong with
	    (LET ((SPECIAL:MY-GLOBAL-FLAG 43)
		  (SPECIAL:PRINT-PRETTY T))
	      ...)
    or
	    (DEFUN FOO (A B SPECIAL:C) ...)

    It's cheap to detect, too, in interpreter or compiler: just check the
    package cell.  This I like. Too bad it's too late.

    An ugly suggestion is to ADD this mechanism to the language without
    removing the declaration syntax yet, and let people phase over during
    the next year.  Ugh, bletch.

I certainly did not intend to hint at such a thing. While it might be 
appropriate for a user program to put all its specials on one package and
all its non-specials on another, or even appropriate for it to be possible
for a whole package to somehow be declared to have implicitly special 
variables (perhaps unless explicitly declared LEXICAL), it is not reasonable 
to make every utility's specials share the same namespace!

Your suggestion is tantamount to saying that package information should be
ignored for variables and used only by EQ and function lookup since the package
of a lexical variable almost never matters -- ie, how many people do you
expect to write:
 (DEFUN F (FOO:X BAR:X) (+ FOO:X BAR:X))
? On the other hand, you might well expect someone to write:
 (DEFUN AVERAGE-LINEL () (// (+ FOO:*LINEL* BAR:*LINEL*) 2))
and certainly
(DEFUN AVERAGE-LINEL () (// (+ SPECIAL:*FOO-LINEL* SPECIAL:*BAR-LINEL*) 2))
would be a -real- step backward.

Adopting a solution like this would mean that programs written without 
knowledge of each other might collide very badly when loaded into the same
environment for some application that wanted to compose them. 

Clearly unacceptable.