[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Poor excuse for packages
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)
(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))
(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.