Issue: KILL-PACKAGE (Version 3)

[Jon L White <jonl@lucid.com>]

re: Current Practice:
      . . .  
      Lucid Common Lisp provides DELETE-PACKAGE but the argument must be a
      package object.

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

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

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


       The principal effect of deleting the package is that the name and
       nicknames of the designated package cease to be recognized package
       names.

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


       DELETE-PACKAGE returns T (if the deletion attempt was successful).


and NIL otherwise?


-- JonL --