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


References:     IN-PACKAGE (p183)
Category:       CHANGE
Edit history:   07-Jul-88, Version 1 by Pitman
Related-Issues: DEFPACKAGE
Status:	        For Internal Discussion

Problem Description:

  There are two typical uses for IN-PACKAGE -- to define/create a package
  and to select a package. The fact that these two purposes have been
  given to the same function has led to reduced error checking.


  Eliminate the ability of IN-PACKAGE to create a package on demand.
  Require IN-PACKAGE to signal an error if the package does not exist.

  Eliminate the :NICKNAMES and :USE arguments to IN-PACKAGE, since they
  are no longer needed.

  Clarify that DEFPACKAGE is the preferred way to declare a package,
  and MAKE-PACKAGE is the preferred way to construct a package at runtime.

  Eliminate the compile-time processing requirement for all package-related
  functions except IN-PACKAGE and DEFPACKAGE.

Test Case:

  #1: (IN-PACKAGE 'NO-SUCH-PACKAGE) 		;signals an error

  #2: (DEFPACKAGE FOO ...options...)		;defines/creates a package
      (IN-PACKAGE 'FOO)				;selects an existing package


  This would greatly improve error checking and modularity, with only minimal
  loss of functionality. Any call to IN-PACKAGE which really needed to
  demand-create a package could be rewritten as a DEFPACKAGE followed by an

Current Practice:

  Probably no one implements this behavior since it's in direct
  contradiction of both the definitions and numerous examples in CLtL.

Cost to Implementors:

  This change would be straightforward to implement.
  The cost may not be trivial in all cases, but should not be very large.

Cost to Users:

  In most cases, minor syntactic changes to some files would be necessary.

  In many cases, no changes would be necessary since files may already be
  doing IN-PACKAGE in situations where the author is hoping he's made sure
  the real package declaration is already loaded.

Cost of Non-Adoption:

  Reduced error checking.

  Less modular code.


  Errors due to demand-creation of a package by IN-PACKAGE without appropriate
  uses of the :USE or :NICKNAMES or without appropriate calls to EXPORT, etc.
  afterward would be easier to detect.

  Modular package declarations would be encouraged.


  The fact that IN-PACKAGE is currently ambiguous about intent (whether the
  package should exist already or not) is clearly not aesthetic. This change
  would be an aesthetic improvement.



  As written, this proposal is necessarily contingent on DEFPACKAGE:ADDITION.
  Note, however, that the attempt by this proposal to reduce the set
  of arguments allowed to IN-PACKAGE is not inconsistent with the attempt by 
  DEFPACKAGE:ADDITION to increase the set of arguments. That proposal,
  which is a compatible addition, presupposes that IN-PACKAGE is still
  usable both for selection and creation, so it correctly attempts to
  generalize the arguments it requires. This proposal, which is an
  incompatible change, uses DEFPACKAGE as a foothold to change the model
  of how IN-PACKAGE is used -- only once that new model is in place does
  it make sense to consider eliminating arguments to IN-PACKAGE.