[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: DIGITP's second arg, and error conditions

In the following note:
    Date: 2 October 1980 00:17-EDT
    From: KMP,JAR at MIT-MC
    .  .  .
    (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.
	 .  .  .
      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.
both DIGIT-WEIGHT and DIGIT-NAME are accepted, so I might suggest that DIGITP 
act as per my note of 1 October (reproduced below).  But I didn't see any 
consideration in this proposal of the question of when to signal a 
:WRONG-TYPE-ARGUMENT error;  would you accept my proposal for that?
    Date: 1 October 1980 20:25-EDT
    From: Jon L White <JONL at MIT-MC>
    .  .  .
    Should either (or both) signal an error when the argument is not
    implicitly a character?  I think perhaps DIGIT-WEIGHT should; but DIGITP
    could, like FIXNUMP, be a total function.

Now, as for "DIGIT-NAME", note GLS'S reply that CHPROP already suggested 
"DIGIT-CHAR";  furthermore, there is the question of how the result of 
DIGIT-CHAR should be presented, namely which of the various representations 
for characters should be used.  There is the least confusion, I think, if 
its result is like the output of the LISPM function CHARACTER --- namely a 

Now back to DIGITP's second arg:
    Date: 1 October 1980 20:25-EDT
    From: Jon L White <JONL at MIT-MC>
    .  .  .
       DIGITP --  returns only "True" or "False" (however encoded) and
		  is "True" only for the 10 decimal digits.
So why even bother with a second arg to DIGITP if DIGIT-WEIGHT is added?
In fact, the reason that the whole DIGITP question came up at all was
that RWK boggled when he saw DIGITP returning a useful value (instead
of "True" or "False");  at that time, I doubt that anyone other than myself
had ever used that "useful" value, and that all other users presumed the
Webster's dictionary definition, i.e. one of the ten digits 0, 1, ... 9.
But if DIGITP is to admit a second arg (and as KMP suggests it might make 
for more concise code if it did), then it would be more consistent still
to have it return "True" or "False" rather than the DIGIT-WEIGHT.

Similarly, I like KMP's suggestion that DIGIT-WEIGHT admit an optional
second arg (defaulty 36.) for radix;  it still isn't a fixnum function
(in the MacLISP sense) since it could return () on non-digital