[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: SHARPSIGN-PLUS-MINUS-NUMBER (Version 3)
- To: CL-Cleanup@SAIL.STANFORD.EDU
- Subject: Issue: SHARPSIGN-PLUS-MINUS-NUMBER (Version 3)
- From: masinter.pa@Xerox.COM
- Date: 23 May 88 17:38 PDT
- Line-fold: no
My notes from the last meeting were "Codify current practice: allowed, read in base 10."
Here 'tis. If it hasn't aged, maybe we have.
References: #+ (p358), #- (p359), *features* (p448),
Parsing of Numbers and Symbols (p339-342)
Edit history: Revision 1 by KMP 03/01/87,
Revision 2 by KMP 03/09/87 (address potential numbers)
Version 3 by Masinter 23-May-88, revive
Features which are not symbols are currently not allowed.
Unfortunately, machine names are desirable 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 .
Extend the definition of #+ and #- on pp358-359 to say that
integers are allowable as features. Define that the feature-spec
reader binds base to 10 so that people don't have to do #+7020 to
find the 3600 feature in base 8.
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")))
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
[We also need to nail down the rules for what package is used in
the feature-spec reader. I've put that in a separate proposal.]
Extend the definition of *features* on p448 to say that it is a
"list of symbols and/or numbers".
There is no deep-rooted reason why numbers shouldn't work.
The current restrictions are somewhat arbitrary. This would
allow arbitrary alphanumeric strings (subject to restrictions
about potential numbers) to be used as identifiers in a
Some implementations already allow this (though most probably
do not bind base to 10 -- I've seen some octal feature names).
Other implementations signal an error if they see what they
believe to be an invalid feature name (such as a number).
Cost to implementors:
Changes to implementations not already supporting this feature
would probably be very minor.
Cost to Users:
Some users would view this as an enhancement; others as a bug fix.
I don't think it would be seen in a negative light.
A restriction which seems arbitrary to some people would be removed.
No issues not already addressed above.
KMP initiated this proposal and thinks that it would be a
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."