Issue: DEFPACKAGE (Version 7)

[Barry Margolin <barmar@Think.COM>]

    Date: Wed, 7 Dec 88 15:00:53 PST
    From: Jon L White <jonl@lucid.com>

    re: Date: 6 Dec 88 18:02 PST
	From: masinter.pa@Xerox.COM
	Subject: Re: Issue: DEFPACKAGE (Version 7)

	Our intent in "at variance" was specifically to make the behavior of
	DEFPACKAGE undefined in the example you cited. We specifically did not want
	to proscribe that DEFPACKAGE had to resolve conflicts according to "the
	normal error handling of the package modification functions", because
	DEFPACKAGE, when it occurs at the beginning of a file during compilation,
	might have some extra processing associated with it that would make such
	"normal error handling" difficult or impossible.

    What you mean "We", white man?

    We specifically do mean that DEFPACKAGE must resolve name conflicts 
    caused by the creation of such a package. There is an entire section
    of the proposal dealing with the order of sub-events so that, for
    example, shadowing can be done before "using", and thus prevent
    spurious name conflicts.

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.

    re: Date: Wed, 7 Dec 88 00:31:55 EST
	From: barmar@Think.COM
	Subject: Issue: DEFPACKAGE (Version 7)

	In that case, I guess I want to know what the writeup meant when it
	said "At most, the existing package will be modified to reflect the
	new definition".  Is this just a suggestion to implementors about what
	they MIGHT do, but not a requirement to do it?

    The very sentence in the proposal just before the one you are wondering
    about explains what "At most ..." means.  The context is:
	If the specified name already refers to an existing package, then the 
	name-to-package mapping for that name is not changed.   At most, the 
	existing package will be modified to reflect the new definition;  it is 
	undefined what happens if the new definition is at variance with the 
	current state of that package.  If one of the specified nicknames already
	refers to an existing package, then an error is signaled just the same
	as MAKE-PACKAGE would.  See the issue PACKAGE-DELETION for undoing the
	name-to-package mapping.

The additional context doesn't help.  The first sentence of the
paragraph only says that it won't do one particular thing.  The problem
with the phrase "at most" is that it assumes a well-defined set of
possible results, so that one can decide whether a particular result is
within that set.

    You may not however assume that effect is "benign"!  In general, package 
    changes are frequently _not_ benign; so continuing at all carries some
    risk of disaster.  Yet so often, many common, trivial changes ought to be
    overlooked -- the implementation can be a bit "forgiving"; for that very 
    reason we decided to allow an implementation-dependent recovery action,
    rather than requiring an error signal.

The intent of the "undefined but benign" (I don't think this is Kathy's
terminology, but I don't remember what it is) error situation is to
specify that while the results are implementation-dependent, they don't
directly result in fatal errors.  Calling DEFPACKAGE twice with the same
package name but different options should never damage the Lisp
environment, but it might result in unexpected package relationships;
compare this with the specification of the results of (+ 'a 'b), which
might result in a core dump on a conventional architecture with high
speed and low safety.

                                                barmar