Issue: DEFPACKAGE (Version 7)

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

re: He's referring to the name conflicts caused by re-executing a DEFPACKAGE
    with different options, not the name conflicts resulting from an initial
    DEFPACKAGE.  The issues aren't the same.  In particular, if the second
    DEFPACKAGE has a :SHADOW option, it will be executed after the first
    DEFPACKAGE's :USE, violating the intent of DEFPACKAGE.

Somebody's confused here.  If a second (or subsequent) call to DEFPACKAGE
supplies a :SHADOW option, that will in no way cause a violation or
conflict with the pre-existing package.  Shadowing is always safe.  The 
ordering constraints of the proposal are there to insure that a single 
DEFPACKAGE call has only one interpretation as to whether it causes name 
conflicts or not;  as such, DEFPACKAGE really can use "the normal error 
handling of the package modification functions".   If you are worrying
about how to merge two different definitions, then that is a different
question [see below for more on "merging" definitions.]

As to your basic question --- what it means "at most the existing
package will be modified" -- I don't think there are very many options
such that one needs to wonder about it.  The only possible options are
set by the pattern of other CL defining forms:
   (1) create a new <frob>, abandoning the old <frob> and updating
       the global name-to-<frob> mapping   [e.g., DEFUN, DEFPARAMETER]
   (2) alter the existing <frob>, without changing the global 
       name-to-<frob> mapping  [e.g., IN-PACKAGE, and DEFMETHOD]
   (3) "undefined"  [sigh, probably DEFTYPE]

At one time, I had worked out a partial prescription for how to merge
an existing package definition with the new redefinition.  However,
many folks objected to this level of detail being in the portable
standard.  So that is why the current status of redefinition is more
or less "undefined";  but I don't think implementators will be at a loss
to come up with variations on "merging" algorithms.  When the variations
between such mergings becomes a problem, then I suppose we can have
another cleanup issue to settle it more concretely.  But right now it
is undefined except in so far as it is licensed to "modify" the 
existing package.

Possibly your concern is that you are implicitly worring about the
consequences of one particular merging algorithm, without specifically
saying which one you are thinking about?


Re: "benign"

Well, this cannot be left up to the imagination.  The naive meaning here 
must not imply that you are safe from catastrophic errors.  If what is 
meant is "maintain memory integrity" or "cause no hardware or operating 
system exceptions", then this would have to be spelled out clearly.



-- JonL --