[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: Snyder%hplabs.csnet@CSNET-RELAY.ARPA
- Subject: feature names
- From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
- Date: Fri, 28 Jun 85 11:41 EDT
- Cc: Common-Lisp@SU-AI.ARPA
- Comment: Remailed at SU-AI after delay caused by dist list error.
- In-reply-to: <8506251758.AA25905@HP-VENUS>
Date: 25-Jun-85 09:57:28
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...