SHARPSIGN-PLUS-MINUS-NUMBERUnfortunately, machine names are used as features. Since some machines are named only by a number (eg, 360, 3600, 8600, 8080, ...) there is no way to use these names as features. Alternate, less mnemonic feature names, must be contrived.
`Potential numbers' (as described on p341) should be addressed specifically if only to say that they are still illegal. There should be no ambiguity about what is legal and what is not. An example of such a symbol is 68020A .
In the case of `potential numbers' (as per p341) in a feature spec, say that they are allowed for use in this context. If the implementation does not support the syntax in question, it is permitted to treat the syntax as if it denoted a feature which was known not to be present. That is, in any implementation where a potential number which is denoted by a character sequence <X> can be parsed by the reader as either a number or a symbol, then #+<X> will skip the next form iff the expression (MEMBER (LET ((*READ-BASE* 10.) (*PACKAGE* (FIND-PACKAGE "KEYWORD"))) (READ-FROM-STRING "<X>")) *FEATURES*) yields false, without prejudice to decision about whether <X> denotes a number or a symbol. If <X> cannot be read by the reader because it is a potential number, then #+<X> will skip the next form as if any feature <X> might have been intended to denote was not present.
Extend the definition of *features* on p448 to say that it is a "list of symbols and/or numbers".
Comparison is performed by EQL.
Other implementations signal an error if they see what they believe to be an invalid feature name (such as a number).
Steele asks about treatment of potential numbers, such as #+68020a . Revision 2 of this proposal addresses that issue, by explicitly stating that this is allowed.
Fahlman reluctantly supported version 1 of this proposal since some implementations support numbers here and since the purpose of this feature is to allow selection of such implementations. He wishes people would write Symbolics-3600 rather than 3600 since it isn't clear that 3600 is meaningful in the abstract. He wants to see the potential number issue treated, however.
KMP thinks that the problem of meaningfulness is not unique to numbers. Many feature names with only alphabetic characters could be likewise criticized. In practice, brevity is important because AND and OR will greatly increase horizontal size of feature-spec expressions and often it's desirable to still have enough room to the right to grind the conditionalized expression.
Dick Gabriel opposed this proposal: "unless there is a compelling reason to do otherwise, it is best to have as few different rules and concepts in a language as possible.
Let `#+' represent either `#+' or `#-'. Currently #+<object> can be such that <object> is a symbol or a boolean expression. I don't see any gain in expressive power if we extend this to include numbers, yet we've extended the complexity of the language a little bit.
Furthermore, the examples given are not compelling at all - someday soon some people will not know what I mean when I say I mailed this message from a 10.
Symbolics-3600, IBM-360, MC68020A - these are proper machine names and hence proper feature names.
Finally, an expression like #-3600 looks like an arithmetic expression or a slip of the TIP for simply -3600." TITAN TITAN
TIMESROMAN Å ¿!*ÿd} I+7Õzº