Cleanup Issue EXPORT-IMPORT

Status
For Internal Discussion
Category
CLARIFICATION
References
EXPORT (p186)

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 (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 (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 Cases

(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.

Edit History