Features

[Jon L White <edsel!jonl@labrea.stanford.edu>]

re: *features*  . . . It is unclear to me from this whether an implementation 
    should compare the features as the symbols themselves or as their 
    printnames.  Lucid does the latter, which seems more reasonable given 
    the potential for confusion involving packages. They also put their 
    features in the keyword package, which is good defensive programming.

Lucid Common Lisp uses MEMBER as the test of *features* entry; and for
symbols, this becomes an EQ check, rather than "same-printname-p"; it also
implements the x3j13 proposal described in the next paragraph.

X3J13 is considering a proposal to require the setting of *package* to be
the KEYWORD package during the scope of reading the forms under a #+ or a 
#-.  This will tend to give the appearance of "namestring" comparison rather
than EQ only because, for example,  #+LUCID  will be read in the feature as
:LUCID, and the search on *features* will be for that symbol.  The X3J13 
proposal would permit reading in feature names like #+MACSYMA:HYPERLINEAR,
in which case the member test would be with the symbol MACSYMA:HYPERLINEAR.

Since *features* is an ordinary special variable (no contradiction in terms,
I hope!  I only mean to say that it is "bindable" and not restricted to being
a "global" parameter), then nothing prevents you from pushing all kinds of
garbage on it.  Say, 3.14159.  But no consensus exists yet as to how the
#+ and #- syntax might interface to non-symbol entries.



-- JonL --