features

["Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>]

It was clear at the time we let #+ and #- into the language that these
were total kludges and were being kept around almost entirely for
reasons of compatibility with existing code.  For the cases that they
can handle, they are convenient enough, but I think it would be a major
mistake to try to extend them by letting them take an arbitrary
extension to evaluate, as Paul the Greek proposes.  There are many
problems, among them being the problem of which Lisp interpreter is used
to evaluate the expression in question if the #+ stuff is being used to
allow the same file to work in, say, Common Lisp and Maclisp.

I think that by far the simplest solution is to make #+foo treat the
symbol FOO as a keyword, despite the lack of a leading colon in this
context.  This minimizes the possibilities for subtle package lossage of
the type Moon describes.  Yes, it would then be possible that packages
developed in total ignorance of each other might choose confliciting
feature keywords; on the other hand, such packages have an equally great
chance of choosing conflicting package names, so there has to be some
modest amount of coordination if they are to run together.  I think that
this is a change and not a clarification, however -- there's no way to
read the current manual as specifying this conversion to keywords.

I think that putting all these symbols in the Lisp package (as external
symbols) is not workable.  For ont thing, this will often result in some
internal symbol in Lisp being unintentionally made external, and then
when another package imports Lisp it is in for some unpleasant
surprises.

The manual is quite clear that the features are to be symbols (or lists
that are boolean combinations of symbols), and I don't see any reason to
extend that.  #+3600 can read the string "3600" as the name of a
(keyword) symbol.  This avoids all radix lossage.

-- Scott