Re: DIGITP

[KMP at MIT-MC, JAR at MIT-MC]

Jonathan and I have put together our thoughts on the issue. We begin by
summarizing the issues (perhaps oversimplifying somewhat, for the sake
of conciseness) of the DIGITP controversy:

* JAR suggested in CHPROP that DIGITP might want an optional 2nd arg 
  defaulting to decimal 10.
* RWK complained that (DIGITP #/q) returns non-().
* JONL noted that DIGITP returns info about the weight of a digit and
  that this needs to be compared to IBASE to achieve a useful end.
  eg, (LET ((VAL (DIGITP x))) (AND VAL (< VAL radix) VAL))
  JONL's comments were repeated a number of other times, throughout,
  pointing repeatedly to CHPROP and its descriptions of digit weights.
* Moon suggested that perhaps DIGITP should look at IBASE to start with.
* GLS brought up the idea of a 2nd arg to DIGITP again citing the following
  points:
	  1. (DIGITP #/q)	=> ()  would be useful to novices
	  2. (DIGITP #/q IBASE) => 26. would accomplish JONL and Moon's 
					reader needs more concisely than
					the code JONL suggested.
	  3. (DIGITP #/q x)	=> ... could be used for arbitrary radices
					independent of what the lisp reader,
					etc. would want to do with its 
					digitness.
* KMP agreed with 2nd arg idea, noting he had rarely wanted non-{0,1,...,9}
  DIGITPness anyway.
* GSB agreed with 2nd arg idea, noting he had never wanted non-{0,1,...,9}
  DIGITPness anyway.
* RMS said he didn't care what DIGITP did with a 2nd arg, but that with one
  arg it must return non-() only for 0-9.
* DLW agreed with GSB.

------
Now it seems to us that the problem stems from the fact that there is this
winning name called "DIGITP" and everyone wants to see to it that it has
maximally useful semantics without screwing things up. Domains of use include
`machine language' readers (Lisp-like readers, parsers, etc.), human language
readers, and user queries like "Input a number:" -- to name just a few. 
Naive users, especially those experienced with languages that have no other
base available than 10 are likely to be confused by the notion of non-{0-9}
digits. Experienced users will want something that can handle different
ranges of digits and [perhaps] return useful information about the digit as
well.

It would seem to us that the following solution presents itself:

(DIGITP char &optional radix)
  If no radix is supplied, DIGITP returns true (T or #T, as appropriate)
     for the characters 0 through 9, and () for other characters. (This would
     reduce confusion for novices who expected it to be a simple predicate.
     If a sophisticated user thinks this should do something else, maybe he
     wants to look at what (DIGITP char 10.) will do in this formalism.)
  If radix is supplied, DIGITP returns () if the character is not a digit
     in the input base specified by radix. If the character is a digit
     in that radix, then its weight as a digit is returned.

(DIGIT-WEIGHT char)
  Returns the weight of its argument as a digit, independent of base.
  eg, (DIGITP #/A) should return 10. regardless of any radix considerations.
  (DIGITP #/a) should also return 10., since "a" would be the same as "A"
  in number reading.

(DIGIT-NAME value)
  Returns the character which represents the digit whose value is given
  by its argument. eg, (DIGITP 10.) => #/A or ~A or whatever.

-kmp