Re: [Scheme-reports] digit-value

[Marc Feeley <feeley@x>]

On 2012-07-01, at 4:28 PM, Alex Shinn wrote:

> On Sun, Jul 1, 2012 at 9:54 PM, Marc Feeley <feeley@x> 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
Scheme-reports@x
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports