Issue: DEFPACKAGE (Version 7)

[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.


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.
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.



-- JonL --