Re: Issue: DEFPACKAGE (Version 7)

[masinter.pa@Xerox.COM]

After re-reading the discussion, I think the only issue is to define
explicitly what "at variance with the current state of that package" means.
I think a subjunctive definition might be OK, here's a try:

Add to the Proposal: 

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.

If there is a new proposal (rather than an amendment), it might be useful
to add to the discussion:

"One of the most common recipes for disaster is to have differing EXPORTs
in two package definitions, and then to load a file which was compiled in
one of these two enviroments into a "runtime" image that has the other
environment.  The file being loaded may expect to inherit some symbols
(due to their being EXPORT'd from a "used" package at compile time); but 
failing to inherit at "run time", it will create a Doppelganger in the 
current package

Virtually any difference *can* be made to be critical, due to the fact
that the package system is a global database in a flat namespace (there
is no "context" for FIND-PACKAGE).  Leaving it undefined as to how to 
handle varying package re-definitions allows the implementations to
experiment with helpful warnings, recovery stratagies, etc."

How this will get into the standard in the Rationale section is not clear,
but hopefully KC can find a way to cope with it.