Issue: IN-PACKAGE-FUNCTIONALITY (Version 1)

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

Issue:          IN-PACKAGE-FUNCTIONALITY
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.

Proposal (IN-PACKAGE-FUNCTIONALITY:SELECT-ONLY):

  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

Rationale:

  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
  IN-PACKAGE.

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.

Benefits:

  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.

Aesthetics:

  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.

Discussion:

  Pitman supports IN-PACKAGE-FUNCTIONALITY:SELECT-ONLY.

  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.