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

*Subject*: Re: DIGITP*From*: KMP at MIT-MC, JAR at MIT-MC*Date*: Thu ,2 Oct 80 00:17:00 EDT*Sender*: KMP 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

- Prev by Date:
**Re: DIGITP not yet resolved?** - Next by Date:
**Re: MacLisp strings** - Previous by thread:
**[no subject]** - Next by thread:
**Re: DIGITP** - Index(es):