[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: DEFPACKAGE (version 6)
- To: Moon@STONY-BROOK.SCRC.Symbolics.COM
- Subject: Issue: DEFPACKAGE (version 6)
- From: Jon L White <email@example.com>
- Date: Sat, 29 Oct 88 00:14:00 PDT
- Cc: CL-Cleanup@Sail.stanford.edu
- In-reply-to: David A. Moon's message of Wed, 26 Oct 88 22:58 EDT <19881027025834.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
re: :INTERNAL was a typo for :INTERN; I apologize.
Ok, fine by me; we stick with the "VERB" analogy for the options names
rather than the "ADJECTIVE" analogy.
re: An attempt to re-define a package with a smaller set of attributes
should signal a continuable error; at most one such error is to be
signalled per call to DEFPACKAGE, regardless of how many attributes
are being re-tracted; upon continuation, the package is created with
exactly as specified.
Even without the typos I would object to this. It's not clear to me
that signalling an error is the correct response in all programming
environments for evaluating a DEFPACKAGE with fewer attributes.
. . .
I think it would be a much better idea to leave redefinition of packages
undefined, just like redefinition of functions or macros.
I thought the above wording came from a consensus among several people
(who? maybe KMP and vanMelle?); probably that was the week that you were
out. Nevertheless, I strongly disagree that we can leave the redefinition
question completely alone; we simply cannot allow DEFPACKAGE to operate
like DEFUN, where only the name-to-object mapping is changed. [By the
way, even if CLtL doesn't spell it out, "common practice" for more than
20 years says that re-doing a DEFUN or DEFMACRO doesn't alter an existing
function object, but instead simply changes the symbol-function "cell".]
Like CLOS classes and generic functions, packages are a global database
referenced "by name" and incrementally definable; a subsequent redefinition
must give some accountability to the old instances. I'm not at all
impressed that "many people still argue that CLOS got it wrong"; at least
it clearly states that class redefinition isn't merely an alteration of the
-- JonL --