Issue: SHARPSIGN-PLUS-MINUS-NUMBER (Version 3)

[masinter.pa@Xerox.COM]

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.


!
Issue:        SHARPSIGN-PLUS-MINUS-NUMBER
References:   #+ (p358), #- (p359), *features* (p448),
	      Parsing of Numbers and Symbols (p339-342)
Category:     ENHANCEMENT
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

Problem Description:

  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 .

Proposal (SHARPSIGN-PLUS-MINUS-NUMBER:OK)

  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")))
	    (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.

  [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".

Rationale:

  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
  well-defined way. 

Current Practice:

  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.

Benefits:

  A restriction which seems arbitrary to some people would be removed.

Aesthetics:

  No issues not already addressed above.

Discussion:

  KMP initiated this proposal and thinks that it would be a
  worthwhile extension.

  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."