[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
re: . . . You should know the names of all the symbols you import (including
all the symbols exported from packages you use), not only so you don't
get surprised about them being special, but so you don't accidentally
make them special when they shouldn't be. What the package system buys
you is letting this not be all the symbols in the world.
Very astute observation! I believe there's been a proposal to the cleanup
committee which would declare it to be "an error" for someone to redefine a
function in the LISP package. But Common Lisp doesn't even make it "an
error" to put all sorts of garbage into the LISP package (which everybody
*has* to use) and proclaim it INLINE and SPECIAL and all that jazz.
This problem is at once both the beauty of Lisp and its greatest weakness.
LISP has endured all these years because it is an "open system"; user code
-- in a very non-lexical way -- can muck around with the internals of:
Parsing [reader macros]
Compiling [ordinary macros, eval-when computations]
Loading [few, if any constraints, on cross-package reference]
Running [*print-base*, special variables, dynamic fn redefinition]
[ordinary macros, STEP, DEFADVICE, etc]
So it sounds like there is a need for listing all the assumptions that
keep a Common Lisp program sound --
What functions *should* not be redefined
What variables (and fns) *should* not be proclaimed in any way
What types shouldn't be overridden
What defstructs shouldn't be incompatibly redefined
What defstructs shouldn't be extended (via :include)
What package machinations should not be done
[e.g., Puting random external symbols in the LISP pacakge;
Putting symbols "owned" by other packages into KEYWORD;
EXPORTing symbols after a file using them has been compiled.]
. . . ??
The goal is not to make Lisp a strongly-typed language, or any other
"fascist beast", but to promulgate style guidelines which would enable
cooperating programs not to trash one another.
I believe that a reasonable set of such guidlines could be made for the
existing Common Lisp systems.
-- JonL --