issue IN-PACKAGE-FUNCTIONALITY, version 5

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

Here is a new writeup on this issue, incorporating the NEW-MACRO
proposal I had written on a slide at the meeting.  I have made a few
slight rearrangements and rewordings but the basic content is
unchanged. 

Putting on my hat as the chair of the compiler committee, I will
repeat what I said at the meeting: if people think that this is has
become a compiler issue rather than a cleanup issue, we are willing to
take it off your hands.  Let me know.

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

Related-Issues: DEFPACKAGE (passed)
		CONSTANT-COMPILABLE-TYPES

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 and a concise statement of the requirements for
  compile/load consistency.

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

  Add a new macro:

    WITHIN-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.)  Replace it with the following language:

    When a compiled file is loaded, the symbols it contains are interned
    in the same package they occupied when the file was compiled.  A
    necessary condition for a program contained in a file to be a
    conforming Common Lisp program is that, when the source file is
    processed by COMPILE-FILE, all of the symbols in the file be interned
    in the same package they would occupy if the source file were
    loaded directly with LOAD.

  Rationale:

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

    Making WITHIN-PACKAGE a macro rather than a function means that there
    is no need to require COMPILE-FILE to handle it specially.

    The rationale for proposing WITHIN-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.

    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 determined by the compiler.  The
    new language specifies a conformance requirement that is both
    well-defined and implementable.

  Current Practice:

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

  Cost to Implementors:

    The WITHIN-PACKAGE macro can be implemented trivially by using 
    EVAL-WHEN in its expansion.

    The changes required to COMPILE-FILE to support the new conformance
    requirements are also likely to be small.

  Cost to Users:

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

  Cost of Non-Adoption:

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

    The standard will place requirements on implementations which are
    impossible to meet.

  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.  



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. 

  Examples:

    #1: (IN-PACKAGE 'NO-SUCH-PACKAGE) 	;would signal 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. 

  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.
    Some people feel this change would be an aesthetic improvement.
    Others feel that an incompatible change to IN-PACKAGE would merely
    be confusing.


Discussion:

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

  Both proposals represent an incompatible change to the language as
  described in CLtL and will break any program that uses the "Put In
  Seven Extremely Randoms" convention described in section 11.9.

  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.

-------