Issue: EXPORT-IMPORT

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

Issue:        EXPORT-IMPORT
References:   EXPORT (p186)
Category:     CLARIFICATION
Edit history: 26-Jan-88, Version 1 by Pitman
Status:	      For Internal Discussion

Problem Description:

  The description of EXPORT in CLtL says that it makes its argument symbols
  ``become accessible as external symbols in PACKAGE.'' It does not specify
  how much work EXPORT should be willing to go through in order to make this
  happen.

Proposal (EXPORT-IMPORT:YES):

  Clarify that if the symbols which are specified to EXPORT are not in
  [the argument] PACKAGE then EXPORT should do an implicit IMPORT of those
  symbols and then should EXPORT them. 

  Rationale:

    In most cases where a package is going to export symbols from another
    package, the idiom
     (IMPORT '(symbol-a symbol-b ...)) (EXPORT '(symbol-a symbol-b ...))
    must be written. Maintaining both lists consistently is more error-prone
    and it would be simpler if one could just write the EXPORT call and not
    worry about the import.

Proposal (EXPORT-IMPORT:NO):

  Clarify that if the symbols which are specified to EXPORT are not in
  [the argument] PACKAGE then EXPORT should signal a continuable error.
  If continued, EXPORT should IMPORT the indicated symbols and continue.

  Rationale:

    The package system is very tricky and setting things up correctly is
    very difficult. The programmer should be asked to be explicit about
    intent so that the system can diagnose as many potential errors as possible.

Test Case:

  (MAKE-PACKAGE 'EXPORT-TEST-PACKAGE :USE '())
  (EXPORT '(CAR CDR CONS) (FIND-PACKAGE "EXPORT-TEST-PACKAGE"))

Current Practice:

  Symbolics implements EXPORT-IMPORT:NO. (The error we signal says you can
  "Proceed without any special action." which doesn't make it completely clear
  that it will do the implicit import, but that's apparently what happens.)

  [Pitman is pretty sure several implementations implement EXPORT-IMPORT:YES
   because we get a lot of bug reports from people who seem to think this is
   something guaranteed but who cannot cite a passage saying where. Hopefully
   people will volunteer more cases here.]

Cost to Implementors:

  Presumably this change would be very isolated and easy for implementors to make.

Cost to Users:

  EXPORT-IMPORT:YES is upward-compatible, though produces diminished error checking.
  A change to EXPORT-IMPORT:NO might cause some users to have to write an explicit
  call to IMPORT in some package declarations. Since continuing the error mentioned
  in the EXPORT-IMPORT:NO spec will produce the EXPORT-IMPORT:YES behavior, though,
  the incompatibility should be easy to work around in a transition period.

Cost of Non-Adoption:

  Users will continue to be frustrated by a vague description of EXPORT.

Benefits:

  Users will know clearly what EXPORT does in a case which seems to come up fairly
  often in practice.

Aesthetics:

  There are aesthetic pluses and minuses to both approaches. The most important
  thing is to get this nailed down.

Discussion:

  Pitman supports EXPORT-IMPORT:NO.