Issue: SHARPSIGN-PLUS-MINUS-PACKAGE (Version 2)

[Masinter.pa@Xerox.COM]

I rewrote this proposal with only the :KEYWORD option. I added an
endorsement. I added mention of the possibility of a registry in the
discussion. I rewrote some sections to avoid Kent's original
first-person phrasing. I reworded the proposal as a change to the
language rather than a change to CLtL.

I removed the wording in the Rationale which said "Since it's clear that
Common Lisp is not going to handle all of everyone's needs, one of the
most important things we can provide is a well-defined
conditionalization system to allow people to escape to native code."
since I disagree; I think of our work in CL-Cleanup as primarily
oriented toward minimizing the amount of #+ and #- that users need to
perform.  Whether you agree or not, I think the proposal stands without
it.

!
Issue:        SHARPSIGN-PLUS-MINUS-PACKAGE
References:   #+ (p. 358), #- (p. 359), *FEATURES* (p. 448)
Category:     CLARIFICATION/CHANGE
Edit history: Version 1 by Pitman 03/01/87
              Version 2 by Masinter 10-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 to either of these
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.