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.