Issue: IN-PACKAGE-FUNCTIONALITY (Version 3)

[masinter.pa@Xerox.COM]

!
Issue:          IN-PACKAGE-FUNCTIONALITY
References:     IN-PACKAGE (p183)
Category:       CHANGE
Edit history:   07-Jul-88, Version 1 by Pitman
                 7-Oct-88, Version 2 by Masinter (discussion)
                  8-Dec-88, Version 3 by Masinter

Related-Issues: DEFPACKAGE

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.
  Eliminate the :NICKNAMES and :USE arguments to IN-PACKAGE, since they
  are no longer needed.

  The results of calling IN-PACKAGE if the package does not already
  exist are implementation dependent; implementations "should signal"
  an error, or otherwise provide the user with a way to recover from
  the situation. 

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 could allow improved 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:

  As written, no change to implementations is required, but many
  will want to make IN-PACKAGE signal an error.
  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 some 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:

  The cleanup committee supports IN-PACKAGE-FUNCTIONALITY:SELECT-ONLY.
  The dual use of IN-PACKAGE has not been helpful and is confusing.

  Some members support it only if DEFPACKAGE passes; others would like
  to see IN-PACKAGE changed even if DEFPACKAGE were not added to the language.
  However, there might be some compilation problems if IN-PACKAGE
  changes and MAKE-PACKAGE signals an error if the package exists.

  The issue of compile-time processing of package related functions is
  complex, and full of a number of compatibility issues. Should we remove
  the requirement of special compile-time handling of IN-PACKAGE? 
  Should we disallow mid-file switching of *PACKAGE* or package
  use lists? These issues are not addressed here.