Issue: KILL-PACKAGE (Version 1)

[Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: Sat, 1 Oct 88 17:46:55 PDT
    From: Jon L White <jonl@lucid.com>

    Oh, foo, I'm afraid this will have to be called DELETE-PACKAGE.

This part is already dealt with. Your message and my corrected
proposal (Version 2) probably crossed in the mail.

    ...
    Now as to the operation of DELETE-PACKAGE, it differs from your
    proposal on the matter of what to do when some other packages are
    "using" the one to be deleted.  Steele says "signal an error";
    Lucid Common Lisp signals a continuable error, and going on will
    remove the links.  

Well, your stated behavior is at least conservative. Presumably this
means that no one has code the correct operation of which depends on
calling DELETE-PACKAGE on packages which are "in use", so making a
change won't break any of those programs.

I'm inclined to believe it's better to define a useful behavior here
because
 - It's easy to test for that case and guard against it in the
   cases that matter.
 - It's a pain to do the bookkeeping that is otherwise required.

By the way, I kind of agree that it's a little weird to silently
remove the package from the using package's use list, but then again,
deleting a package is not something people do lightly. It turns out
that this situation happens to me on a regular basis, though, because
I often delete a whole bunch of packages, some of which use others.
In that case, I'm happy it doesn't complain about the ones that use
the others because a moment later I'm going to delete them anyway.
But, of course, that's just one data point.

    Although LCL signals an error if the argument isn't a package, it 
    silently returns NIL if the argument is an already de-registered
    package.

I guess we're both inconsistent on this. Probably it should either
signal errors about all kinds of things or be tolerant about all kinds
of things...

    Eric Benson convinced me at one point in time that all
    the the deletors should simply return NIL if they can't do their
    deletory action; this includes giving it totally wrong data.
    How would you feel about that approach?

I'm not really opposed to it, but I'd be curious to get some viewpoints
 from people outside of Lucid and Symbolics who have no vested stake in
this and are listening to evaluating these issues for the first time.

I'll think about putting out a compromise proposal based on this
discussion and any other feedback I get in the next day or two.