From: Krzysztof D. <krz...@gm...> - 2014-02-28 19:24:56
|
On 02/28/2014 10:21 AM, Christophe Rhodes wrote: > Tom Emerson <tre...@gm...> writes: > >> On Fri, Feb 28, 2014 at 7:06 AM, Christophe Rhodes <cs...@ca...> wrote: >>> I think I agree with Stas, that using non-standard characters as digits >>> and expecting them to work as numbers is pain waiting to happen; I think >> [snip] >> >> As I've thought about it, I agree, but the behavior is inconsistent: >> it does support non-ASCII numerals when the radix > 10, which appears >> to be by design since it explicitly looks up the numeric value for the >> character: > > Oh, right, I didn't say explicitly: I think the current behaviour of > digit-char-p (which is unchanged since the Unicode merge, or at least > the great whitespace explosion) is wrong in that it shouldn't actually > consider non-ascii to be digits even for radixes larger than 10. > > Still working on releasing later today. > > Cheers, > > Christophe > There is (as mentioned in #1177986), the CLHS invariant that (alphanumeric x) => (or (alpha-char-p x) (digit-char-p x)). With the current definitions of alphanumericp and alpha-char-p (in terms of Unicode categories), digit-char-p has to handle Unicode digits to be standards-compliant. The other option is to restrict alphanumericp and alpha-char-p to be ASCII-only, which would, IMO, defeat the purpose of Unicode support. kad |