Issue: DEFPACKAGE (version 6)

[Jon L White <jonl@lucid.com>]

re: :INTERNAL was a typo for :INTERN; I apologize. 

Ok, fine by me; we stick with the "VERB" analogy for the options names
rather than the "ADJECTIVE" analogy.


re: 	An attempt to re-define a package with a smaller set of attributes 
	should signal a  continuable error; at most one such error is to be
	signalled per call to DEFPACKAGE, regardless of how many attributes 
        are being re-tracted; upon continuation, the package is created with 
        exactly as specified.

    Even without the typos I would object to this.  It's not clear to me
    that signalling an error is the correct response in all programming
    environments for evaluating a DEFPACKAGE with fewer attributes.
    . . . 
    I think it would be a much better idea to leave redefinition of packages
    undefined, just like redefinition of functions or macros.

I thought the above wording came from a consensus among several people 
(who? maybe KMP and vanMelle?); probably that was the week that you were 
out.  Nevertheless, I strongly disagree that we can leave the redefinition 
question completely alone; we simply cannot allow DEFPACKAGE to operate
like DEFUN, where only the name-to-object mapping is changed.  [By the
way, even if CLtL doesn't spell it out, "common practice" for more than
20 years says that re-doing a DEFUN or DEFMACRO doesn't alter an existing 
function object, but instead simply changes the symbol-function "cell".]

Like CLOS classes and generic functions, packages are a global database
referenced "by name" and incrementally definable; a subsequent redefinition
must give some accountability to the old instances.   I'm not at all 
impressed that "many people still argue that CLOS got it wrong";  at least 
it clearly states that class redefinition isn't merely an alteration of the 
name-to-class mapping.


-- JonL --