issue IN-PACKAGE-FUNCTIONALITY, version 7

[sandra%defun@cs.utah.edu (Sandra J Loosemore)]

Here's a new version of the writeup for this issue.  Since Pitman has
indicated he wants to withdraw the SELECT-ONLY proposal, it has gone
away.  I also fixed the typo noted by Moon. 


Issue:          IN-PACKAGE-FUNCTIONALITY
References:     IN-PACKAGE (p182-183)
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
                12-Dec-88, Version 4 by Masinter
	        20-Jan-89, Version 5 by Loosemore
		30-Jan-89, Version 6 by Loosemore
		10-Mar-89, Version 7 by Loosemore

Related-Issues: DEFPACKAGE (passed)
		COMPILE-FILE-SYMBOL-HANDLING

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.

  A more general problem is that the "Put In Seven Extremely Randoms" 
  convention described in CLtL is now recognized by many people as being
  unsatisfactory for both package definition and package selection.
  The DEFPACKAGE macro provides a much cleaner mechanism for package
  definition, but there is still a need for a convenient way to select
  a package that has well-defined compilation semantics.


Proposal (IN-PACKAGE-FUNCTIONALITY:NEW-MACRO):

  Add a new macro:

    SELECT-PACKAGE name						[macro]

    This macro causes *PACKAGE* to be set to the package named NAME,
    which must be a symbol or string.  An error is signalled if the
    package does not already exist.  Everything this macro does is also
    performed at compile time if the call appears at top-level.

  Remove the function IN-PACKAGE from the standard.

  Remove the second paragraph of section 11.7 in CLtL.  (This includes
  the requirement for special compile-time treatment of the various
  package functions.)


  Rationale:

    This could allow improved error checking and modularity, with only
    minimal loss of functionality.

    The rationale for proposing SELECT-PACKAGE as a replacement for
    IN-PACKAGE, rather than simply changing IN-PACKAGE to have this 
    behavior, is that such an incompatible change would be confusing to
    many people, and would make it more difficult to detect obsolete
    usages.  There is nothing in this proposal that would prevent
    implementations from continuing to provide IN-PACKAGE as an extension.

    Making SELECT-PACKAGE a macro rather than a function means that there
    is no need to require COMPILE-FILE to handle it specially.  Since
    DEFPACKAGE is also defined to side-effect the compilation environment,
    there is no need to require any of the package functions to be treated
    specially by the compiler.

    The language in section 11.7 of CLtL puts the burden on
    implementations of ensuring that all symbols in a file which is
    compiled and loaded end up in the same package that they would if the
    source file were loaded interpretively.  No implementation can
    possibly meet this requirement because, in general, the runtime
    behavior of the program cannot be predicted by the compiler.

  Current Practice:

    Probably no one implements this behavior exactly since it's an 
    incompatible change to CLtL.

  Cost to Implementors:

    The SELECT-PACKAGE macro can be implemented trivially by using 
    EVAL-WHEN in its expansion:

    (defmacro select-package (name)
        `(eval-when (eval compile load)
	     (setq *package*
	           (or (find-package ',name)
		       (error "Package ~s does not exist." ',name)))))

    The changes required to COMPILE-FILE to remove the magic treatment
    of the package functions are also likely to be small.

  Cost to Users:

    In most cases, minor syntactic changes to some files would be
    necessary.  Programmers that are now using the "Put In Seven
    Extremely Randoms" convention will probably find it straightforward
    to convert their code to do a DEFPACKAGE followed by a 
    SELECT-PACKAGE.

  Cost of Non-Adoption:

    The specification of COMPILE-FILE will be much more difficult to
    understand.

    The standard will require compilers to solve the halting problem.

  Benefits:

    Modular package declarations would be encouraged and errors due
    to demand-creation of packages would be easier to detect.

    The specification of COMPILE-FILE will be simplified.

    There will be a clear statement of the requirements for program
    conformance, as relating to usage of packages.

  Aesthetics:

    The fact that IN-PACKAGE is currently ambiguous about intent (whether
    the package should exist already or not) is clearly not aesthetic.
    Removing it can't be any worse.

    The fact that the currently stated requirements for handling of
    the package functions by the compiler are not implementable is
    clearly not aesthetic.


Discussion:

  The dual use of IN-PACKAGE has not been helpful and is confusing.

  Some people may find proposal NEW-MACRO more palatable if it merely
  deprecated IN-PACKAGE, instead of removing it entirely.

  Loosemore and Moon support proposal IN-PACKAGE-FUNCTIONALITY:NEW-MACRO.

  Pitman says:
    I support NEW-MACRO, though would really prefer you change "remove" to
    "deprecate".  Making this an incompatible change is gratuitous.
-------