[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: KILL-PACKAGE (Version 3)
- To: KMP@STONY-BROOK.SCRC.Symbolics.COM
- Subject: Issue: KILL-PACKAGE (Version 3)
- From: Jon L White <email@example.com>
- Date: Wed, 5 Oct 88 17:22:31 PDT
- Cc: CL-Cleanup@SAIL.Stanford.EDU
- In-reply-to: Kent M Pitman's message of Tue, 4 Oct 88 18:04 EDT <881004180459.7.KMP@BOBOLINK.SCRC.Symbolics.COM>
re: Current Practice:
. . .
Lucid Common Lisp provides DELETE-PACKAGE but the argument must be a
Nope. It works with "packages" exactly as the rest of this proposal says.
re: Proposal (KILL-PACKAGE:NEW-FUNCTION):
Introduce the function DELETE-PACKAGE, described as follows:
DELETE-PACKAGE package [Function]
Deletes PACKAGE from all package system data structures. PACKAGE may
be either a package or the name of a package.
If PACKAGE is a package name (i.e., not type PACKAGE) which does not
currently name a package, a correctable error is signalled. If
continued, no deletion action is attempted. Instead, DELETE-PACKAGE
immediately returns NIL.
Although this is the current Lucid practice, EB and I prefer to just
return NIL here. We must consider that DELETE-PACKAGE is only the
tip of the iceberg for retracting global data structures. There really
needs to be a DELETE-DEFSTRUCT and DELETE-DEFTYPE too. So whatever is
done for the error semantics of one of these ought to be consistent
for all three.
If PACKAGE is a package object (i.e., an object of type PACKAGE)
which has already been deleted, no error is signalled and no further
deletion action is attempted. Instead, DELETE-PACKAGE immediately
If the designated package is used by other packages, a correctable
error is signalled. If continued, the effect of UNUSE-PACKAGE is
done to remove any dependencies, causing its external symbols to stop
being accessible to those packages. Once this is done, DELETE-PACKAGE
goes on to delete the package as it would have if no conflict had
I wouldn't use the word "conflict" here, since it has a technical meaning
in the context of packages (CLtL p178) that is somewhat counter to its
The principal effect of deleting the package is that the name and
nicknames of the designated package cease to be recognized package
Any symbols in the designated package still exist after this function
is called. If their home package was not the package to be deleted, the
home package will be unchanged. If their home package was that package,
the home package after this operation is unspecified; the effect of
printing such symbols is also unspecified.
The phrase "still exist" seems odd to me. Perhaps a better way to say it
is that the symbols entered in a package are not modified except possibly
for the symbol-package slot of those homed in that package.
The designated package persists after this function is called.
PACKAGEP is still true of it, but PACKAGE-NAME will return NIL.
The effect of any other package operation on PACKAGE once it has been
deleted is undefined.
Again, the word "persists" is confusing to me. What else could it do?
automatically, self-GC? A single sentence encapsulating what you are
trying to say here could go into the above paragraph: "The principal
DELETE-PACKAGE returns T (if the deletion attempt was successful).
and NIL otherwise?
-- JonL --