[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Scheme-reports] Character/string case and the unicode module
- To: scheme-reports@x
- Subject: [Scheme-reports] Character/string case and the unicode module
- From: Jeronimo Pellegrini <j_p@x>
- Date: Sun, 8 May 2011 01:29:04 -0300
According to section 6.3.5 string-upcase, string-downcase
and string-ci* procedures are in the (scheme unicode) module.
But since section 1.3.1 mandates that modules are implemented
in theor totality or not at all, then this means that an
ASCII-only implementation cannot offer those procedures
except if it provides the full Unicode module.
The report mentions also that an ASCII-only implementation
may use the identity function for normalization (section 6.3.5,
in the paragraph following string-ni=?.
So if I understand correctly, in order to have "string-upcase"
in an ASCII-only system I'd have to have aliases like
(define string-ni=? string=?)
(define string-ci=? string=?)
Is that correct?
That's somewhat strange. (I also see that the predicate
char-upper-case? in is (scheme base), while char-upcase
for transforming characters is in (scheme unicode)).
If this is correct, then the programmer would have to write
(import (scheme unicode))
in order to use string-upcase (and char-upcase and lots of other
procedures perfectly meaningful for), even though that implementation
has no Unicode support.
Should the case-handling procedures really be in the unicode module?
Or perhaps they "could be rebound" when the unicode module is
At least Chicken starts without Unicode support by default, and
changes behavior dynamically after the utf8 egg is loaded by
rebinding string-related procedures:
#;1> (string-length "ááá")
#;2> (use utf8)
#;3> (string-length "ááá")
Scheme-reports mailing list