CLHS: Issue SHARPSIGN-PLUS-MINUS-PACKAGE Writeup

#

## Issue SHARPSIGN-PLUS-MINUS-PACKAGE Writeup

    Issue:        SHARPSIGN-PLUS-MINUS-PACKAGE
    References:   #+ (p. 358), #- (p. 359), *FEATURES* (p. 448)
    Category:     CLARIFICATION/CHANGE
    Edit history: Version 1 by Pitman   01-Mar-87
                  Version 2 by Masinter 10-Nov-87
                  Version 3 by Masinter 14-Nov-87

    Problem Description:

    No information is provided in the description of #+ and #- (pp. 358-359) about
    what package the features are read on.

    In some systems, the current package is used. Since there is no wording in CLtL
    to the contrary, it's reasonable to assume that this would be done, but a
    consequence of this is that you must be much more sensitive to the package
    you're in at any given time when using #+ or #- even for system-provided
    features. (This is a problem if the LISP package can contain only the symbols in
    CLtL because system-provided features will likely not have the names of symbols
    on LISP and hence will require package prefixes. Having a symbol named
    LISP:SYMBOLICS or LISP:LUCID would not be possible, so something like
    #+Symbolics would not be possible; you'd have to write #+SYSTEM:SYMBOLICS or
    some such, which might get a read error in a non-Symbolics implementation that
    didn't export SYMBOLICS from SYSTEM...)

    In some systems, a canonical package (such as KEYWORD) is used. This means that
    package prefixes are rarely necessary in sharpsign conditionals for
    system-provided features regardless of the current package or restrictions about
    what may be in LISP. (For example, the KEYWORD package can have any symbol so
    it's not a problem to push :SYMBOLICS or :LUCID on *FEATURES*).

    This has implications about what goes on the *FEATURES*  list (p. 448).

    Proposal (SHARPSIGN-PLUS-MINUS-PACKAGE:KEYWORD):

    Specify that the default package while reading feature specs is the keyword
    package. Other packages may be designated by use of explicit package prefixes.

    Symbols on *FEATURES* may be in any package but  that in practice they will
    mostly be on the keyword package because that's the package #+/#- uses by
    default. If symbols in a package other than keyword appear on *FEATURES*, they
    will be seen by #+/#- only if marked by explicit package  prefixes in the
    written feature-spec.

    Clarify that the package of the IEEE-FLOATING-POINT symbol mentioned on p. 448
    is KEYWORD.

    Rationale:

    Making the behavior of #+ and #- well defined is important for people writing
    portable code that manipulate *FEATURES* directly.

    Current Practice:

    Some implementations bind *PACKAGE* while reading feature specs and others do
    not.

    Adoption Cost:

    Changes to implementations to make them conform should be fairly minor if not
    trivial.

    Benefits:

    As currently specified, using #+ and #- in truly portable code can have
    bootstrapping problems, since it is sometimes required to conditionally set up
    *FEATURES* in different ways for different systems.

    Conversion Cost:

    Few changes to user code will be required; code that uses #+ and #- will
    continue to work, although code that manipulates *FEATURES* directly may require
    editing.

    Aesthetics:

    Most users would perceive this as a bug fix either to CLtL or to certain
    implementations.

    Discussion:

    The cleanup committee supports this proposal.

    It might be reasonable to suggest that only vendors should add keyword symbols
    to the *FEATURES* list, and that users should add features on their personal
    packages so that collisions due to user applications were less likely. This idea
    might be a subject of controversy though, so is not part of this proposal.

    It would be useful to create a non-binding registry of feature names (and
    package names) already in use, so that Lisp implementors could pick otherwise
    unused feature names, and users who wanted to write portable code could know
    what feature names were preferred.

Copyright 1996-2005, LispWorks Ltd. All rights reserved.