[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: DEFPACKAGE (Version 7)
- To: Jon L White <email@example.com>
- Subject: Issue: DEFPACKAGE (Version 7)
- From: Barry Margolin <barmar@Think.COM>
- Date: Wed, 7 Dec 88 18:52 EST
- Cc: firstname.lastname@example.org, CL-CLEANUP@sail.stanford.edu
- In-reply-to: <8812072300.AA01408@bhopal>
Date: Wed, 7 Dec 88 15:00:53 PST
From: Jon L White <email@example.com>
re: Date: 6 Dec 88 18:02 PST
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
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
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.