What's in *FEATURES*?

[David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>]

    Date: Fri, 14 Jun 85 09:09:45 EDT
    From: greek@DEC-HUDSON

    It seems to me that, since *FEATURES* is a "global" variable, the items
    in the list should not be package-specific.  The features should pertain
    to the LISP system as a whole, specifying things which parameterize the
    system.

    If a package wants to itemize features within it, that should be done
    with something inside the package (special variable or function).
    Furthermore, even the existence of a package isn't a feature, but rather
    is noted by the presence of its name in *MODULES*.  It's not even
    clear to me that *FEATURES* isn't a constant, but that might be a little
    radical.

    In light of my opinion, features can only be simple symbols, all present
    in the LISP package.  Right?

The problem with that idea is that putting a symbol into the LISP package makes
that symbol be shared among all packages except those that explicitly shadow it.
Thus it is not a good idea to put a lot of extra symbols into the LISP package
in addition to the ones listed in the manual.  If *FEATURES* were a constant,
controlled solely by the implementation, the problem would simply be that
different implementations would have different symbols in the LISP package,
which could be lived with (it happens anyway).  But the #+ and #- syntaxes are
quite convenient and many large programs want to push their own symbols onto
*FEATURES*.  I don't think it's at all a good idea for such symbols to also be
exported from the LISP package.  And it would be silly to have two versions of
#+, one for "system features" and the other for "user features."

The main reason the KEYWORD package exists is to serve as a flat namespace
that, unlike the LISP package, has no effect on inter-package sharing.  Thus
I think the KEYWORD package is the right one for features.