Package Odor

[Jon L White <edsel!jonl@labrea.Stanford.EDU>]

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]
     Interpretation
		[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 --