Issue: DEFPACKAGE (Version 7)

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

re  A DEFPACKAGE is "at variance with the current state of a pre-existing
    package" if the result of executing the DEFPACKAGE with a different name
    would create a package with a different set of exported symbols, a
    different set of USEd packages, with any *more* shadowing symbols, or a
    different set of nicknames.

    A DEFPACKAGE is not at variance with the current state of a pre-existing
    package even if the size of the pre-existing package differs from the :SIZE
    of the DEFPACKAGE form, or if it the pre-existing package has more internal
    symbols.

The second paragraph is fine.  The first is questionable.  I think the
only way to say it is that a DEFPACKAGE form is "at variance" with an
existing package (of the specified name) if any of the following holds:
  (1) the set of used packages specified by the form is different from
      that of the existing package;
  (2) the set of nicknames specified by the form is different from
      that of the existing package;
  (3) the set of exported symbols specified ... ;
  (4) the set of shadowing symbols specified ... ;
  (5) the set of "foreign" symbols specified ... ; [I will use "foreign"
      here to mean a symbol present in a package, but "homed" in some
      other package; these are created via :IMPORT-FROM etc.]
[I hope this is clear enough, and we don't have to explain what it 
means for "the set of used packages" to be different!!!]

Perhaps a better alternative is to give a standard canonical macro-
expansion of DEFPACKAGE into calls on existing functions (such as EXPORT,
FIND-SYMBOL, etc).  This is perfectly doable now, since the proposal 
fully specifies ordering constraints for the subparts that matter.
Of course, an implementation wouldn't be required to use that canonical
expansion, but the semantics would be required to be the same.  The
advantage of this is that it allows for redefinitions using the already
existing notions of name-conflicts etc, without having to specify that
every possible significant change has "undefined" consequences.


Tactical point:  we are nearing the wire for having presentable
proposals.  Some of the feedback of the past two weeks seems reasonable
to incorporate and some of it is "unclear" (to say the least).  Do
you really want to tinker with the wording of any issue already mailed
out between now and net Tuesday?  I would think the safer thing to do
would be to collect a bunch of "amendments" and bring them to the
meeting.  There are probably two dozen minor, non-controversial
amendments, and maybe two or three majorly controversial ones.  But
I'm leary of us "digging a hole" similar to the one opened up at the
very last minute on DECLARE-TYPE-FREE.


-- JonL --