Issue STANDARD-PACKAGE-NICKNAMES
Issue: STANDARD-PACKAGE-NICKNAMES

Forum: Editorial

References: CLHS 11.1.2

Category: CLARIFICATION/CHANGE

Edit history: 2004-07-20, Version 1 by Bruno Haible

Status: For CLiki consideration

Problem Description:

CLHS 11.1.2 gives 'a summary of the names and nicknames of those standardized packages'. Clarify whether this list is exhaustive, or if an implementation may provide other nicknames.

Proposal (STANDARD-PACKAGE-NICKNAMES:EXHAUSTIVE):

Specify in CLHS 11.1.2 that "Standardized packages don't have other nicknames than the ones listed here."

Rationale:

This appears to be what the text meant.

Proposal (STANDARD-PACKAGE-NICKNAMES:ALLOW-MORE):

Specify in CLHS 11.1.2 that "Implementation can add additional nicknames."

Rationale:

This allows for CLtL1 backward compatibility: (in-package "USER") doing the same thing as (in-package "CL-USER").

Test case:

(package-nicknames "COMMON-LISP")
(package-nicknames "COMMON-LISP-USER")
(package-nicknames "KEYWORD")

Current practice:

SBCL implements EXHAUSTIVE, CLISP doesn't.

Cost to Implementors:

EXHAUSTIVE can be expensive for implementors: they may need to change hundreds of package references that use their private nicknames. ALLOW-MORE has no cost.

Cost to Users:

EXHAUSTIVE can be expensive for users in CLtL1 backward compatibility mode. ALLOW-MORE can cause confusion if different implementations use the same nicknames for different packages.

Cost of Non-Adoption:

Unclear spec.

Benefits:

EXHAUSTIVE: Less differences between implementations. ALLOW-MORE: Backward compatibility.

Aesthetics:

Discussion:
  • Bruno Haible supports proposal ALLOW-MORE.
  • Christophe Rhodes supports EXHAUSTIVE. The CLtL1 compatibility afforded by making "USER" a nickname for "COMMON-LISP-USER" is no more than a chimera: since the semantics of some of the operators is different, the compatibility provided is poor. Far better CLtL1 compatibility will be available by having a separate "USER" package, importing most, but not all, of the "COMMON-LISP-USER" symbols, and providing separate implementations of those which were deleted or had their semantics changed.