[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Issue: KILL-PACKAGE (Version 1)

Issue:        KILL-PACKAGE
References:   Packages (pp171-192), PACKAGE-NAME (p184), PACKAGEP (p76)
Category:     ADDITION
Edit history: 30-Sep-88, Version 1 by Pitman
Status:	      For Internal Discussion

Problem Description:

  There is no way to kill a package in Common Lisp.

  This absence makes interactive development work tricky in some
  implementations. If a package is accidentally built incorrectly, the
  user must either rename the package to another package or start over
  by reloading his program in a fresh lisp image.

  Some programs need to create and destroy packages at runtime.
  Without such a facility, some clumsy combination of RENAME-PACKAGE,
  UNINTERN, and UNUSE-PACKAGE is usually made to work. However, it is
  easy for a casual programmer to forget to undo some of the 
  bookkeeping, leading to unwanted effects.


  Introduce the function KILL-PACKAGE, described as follows:

  KILL-PACKAGE package					[Function]

   Kills PACKAGE by removing it from all package system data structures.
   PACKAGE may be a package or the name of a package.

   If PACKAGE names a package which does not exist, or is a package
   object which has been killed already, an error is signalled.

   The name and nicknames of the designated package cease to be
   recognized package names.

   If the designated package is used by other packages, the effect of
   UNUSE-PACKAGE is done to remove that dependency, causing its external
   symbols to stop being accessible to those packages.

   Any symbols in the designated package still exist after this function
   is called. If their home package was not the package to be killed, 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 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 is undefined.

   KILL-PACKAGE returns T.

Test Case:




  (SYMBOL-PACKAGE *FOO-SYMBOL*)        => #<Package "FOO">
  (SYMBOL-PACKAGE *BAR-SYMBOL*)        => #<Package "BAR">




  (PACKAGEP *FOO-PACKAGE*)             => T
  (PACKAGEP *BAR-PACKAGE*)             => T
  (PACKAGEP *BAZ-PACKAGE*)             => T


  (PACKAGE-USE-LIST *BAR-PACKAGE*)     => (#<Package FOO>)
  (PACKAGE-USE-LIST *BAZ-PACKAGE*)     => (#<Package BAR>)



  (SYMBOL-PACKAGE *FOO-SYMBOL*)        => #<Package "FOO">
  (SYMBOL-PACKAGE *BAR-SYMBOL*)        is unspecified

  (PRIN1-TO-STRING *BAR-SYMBOL*)       is unspecified

  (FIND-SYMBOL "FOO" *BAR-PACKAGE*)    is undefined


  (PACKAGEP *FOO-PACKAGE*)             => T
  (PACKAGEP *BAR-PACKAGE*)             => T
  (PACKAGEP *BAZ-PACKAGE*)             => T


  (PACKAGE-USE-LIST *BAR-PACKAGE*)     is undefined



  This facility corrects the deficiency described in the problem description.

Current Practice:

  Symbolics has a function PKG-KILL which satisfies the proposed behavior.
  When a package is killed the home package of all symbols in that package
  are left undisturbed (i.e., local symbols pointing to the killed package).

Cost to Implementors:

  The cost of providing this facility is probably small.

Cost to Users:

  Very slight to none. This change is essentially compatible.

  Some code which cached packages in variables might have to be slightly
  more cautious, but experience in the Symbolics implementation suggests
  that it's really the responsibility of the person doing the KILL-PACKAGE
  to take care of worrying about the effects of having killed the package:
  normal programs need not bother testing a package for validity (using
  PACKAGE-NAME) before using it.

Cost of Non-Adoption:

  Killing a package would continue to be difficult to do portably.


  Better control of storage usage would be available portably.


  No significant effect.


  This was discussed as part of a larger bulk issue of how to undo all
  sorts of definitions. Since that proposal has not gone anywhere 
  (perhaps bogged down under its own weight), this subtopic has been
  broken off for separate discussion.

  Pitman supports this addition.