On 2012-07-01, at 4:28 PM, Alex Shinn wrote: > On Sun, Jul 1, 2012 at 9:54 PM, Marc Feeley <[email protected]> wrote: >> >> On 2012-07-01, at 3:15 AM, John Cowan wrote: >> >>> Marc Feeley scripsit: >>> >>>> What is the rationale for digit-value ? Its usefullness seems limited. >>>> It could be used to parse decimal numbers and convert them to their >>>> numerical value. However, a more general procedure would be useful >>>> to parse numbers in any base: >>> >>> Its purpose is to determine for any digit character (not merely the >>> European digits 0-9) what its numeric value is. For example, >>> (digit-value #\x0663) => 3, because ٣ U+0663 is the Arabic-Indic digit 3. >>> Of course, if the implementation does not support this character, that >>> won't work. >> >> I understand, but why is this useful? It seems rather special purpose (for >> parsing decimal numbers and converting them to their numerical value), but >> this is the purpose of the string->number procedure. Digit-value doesn't >> help me much in parsing hexadecimal. Perhaps I have missed some other use >> case. Moreover, as Peter Bex has pointed out, there is an inconsistency >> with read and string->number. > > The consistency we were making was between digit-value > and char-numeric?, the latter of which was extended to > Unicode semantics. It seemed strange to be able to tell > that a character had a numeric interpretation yet not know > what that numeric value was. > > Neither of these necessarily apply to read or string->number, > since the read syntax is described only for ASCII numbers. > However, since symbols may not begin with any character > with the Unicode numeric property, an implementation would > be free to return (string->number (string #\x0663)) => 3. > > So I think it's more consistent to have digit-value but > consider it a fairly minor issue.
Your arguments suggest to me that string->number should be extended to Unicode (if that's supported by the implementation), and digit-value dropped from the standard. Marc _______________________________________________ Scheme-reports mailing list [email protected] http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
