Features

[David Vinayak Wallace <Gumby@MCC.COM>]

    Date: Mon, 9 May 88 15:45:46 BST
    From: Andrew Watson <mcvax!harlqn.co.uk!andrew@uunet.UU.NET>

I'm answering these in the opposite order to that in which you asked them:

    And *features* (p448):

       "The value of the variable *features* should be a list of symbols that name
       'features' provided by the implementation."

It'd be nice to mark feaures on this list with honest-to-god symbols, to
reduce name collision.   On the other hand you want to be able to check
this list at runtime, (perhaps to see whether or not to load something)
as well as at compile-time.  Presumably the relevent package won't be
available until the feature itself has been loaded.  (i.e. if MACLISP
had had packages, it wouldn't have made sense to do
(COND ((NOT (STAUS FEATURE FORMAT:FORMAT)) (LOAD '(FORMAT))))
since the FORMAT package probably wouldn't yet have been loaded.)

So features are really strings in one namespace; since the Book says
they should be symbols there are really only four portable packages into
which one may safely intern them.  You might as well use keyword; it's
the safest bet.  One reason that forcing them to be symbols is not a bad
idea is that it encourages people to use names which are easy to type,
though this isn't really that important.

    Steele (p358) on the 'feature' in the #+ read-time conditionalization facility:

       "The feature should be the printed representation of a symbol or list. If
       feature is a symbol, then it is true if and only if it is a member of the
       list that is the value of the global variable *features*."

This is the other good reason to make them symbols; hopefully INTERN is
at least as fast as string-equal; plus you'll only have to do it once
per #-/+. Hence the reader macro can do 
(MEMBER (INTERN (READ-SYMBOL BLAH) *THE-KEYWORD-PACKAGE*) *FEATURES*) rather than
(MEMBER ... :KEY #'STRING-EQUAL).

    It is unclear to me from this whether an implementation should compare the
    features as the symbols themselves or as their printnames.

So it seems best to assume (I assume that you're implementing this
feature for Harlequin) that *features* will contain only keywords and
that you can intern what follows #+/- in KEYWORD and search the list
with EQ.

Note that some lisps don't behave this way, so you'll have to defend
agains them.  Reading a package qualifier and throwing it away would
probably be OK.  I hope the CL cleanup committee takes care of this.

Now, what reader syntax should you use to access the *bugs* list?