feature names

[Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>]

    Date: 25-Jun-85 09:57:28
    From: Snyder%hplabs.csnet@csnet-relay.arpa

    If we agree that feature names are to be read in the keyword package,
    then I claim there is no advantage to allowing package prefixes to
    appear in feature names.  In particular, if you have to write MIT:FOOBAR
    to name your feature, why not write MIT-FOOBAR instead?  What makes
    the package system "better" than long names is the ability to be
    "in" a particular package, so you don't have to write the package name
    on each symbol.  If feature names are always read "in" the keyword
    package, then this advantage disappears.  The disadvantage of allowing
    package prefixes in feature names is this business of supressing
    package system errors.

Recall that #+ and #- are not the only things which hack features. Admittedly
in light of that limited context it seems silly, but there is a bigger issue of
what happens to other programs that which to probe the existence of features.
eg, my FEATURE-CASE primitive.

Besides, you already have to be able to suppress package system errors somehow
inside other contexts for the sake of *READ-SUPPRESS*. I'd be willing to go so
far as to say NIL should never be a valid feature so that package errors could
be handled similarly in this context, returning NIL which would be the equivalent
of a non-existent feature...