[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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 --
- From: David Vinayak Wallace <Gumby@MCC.COM>
- From: Andrew Watson <mcvax!harlqn.co.uk!andrew@uunet.UU.NET>