This page is part of the web mail archives of SRFI 75 from before July 7th, 2015. The new archives for SRFI 75 contain all messages, not just those from before July 7th, 2015.
On 7/13/05, Michael Sperber <sperber@xxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote: > > You guys still need to get your terminology straight: The case mapping > is perfectly well-defined---you just don't like the definition. That > I can sympathize with, but the whole case-folding issue doesn't have > any easy solutions, as you point out. [Please indicate where I've mistaken my terminology and I'll correct it.] The case mapping does not match the case mapping defined by the official Unicode standard, locale-aware or otherwise. What the SRFI defines is a hack, using only one part of the Unicode case mapping as provided in the UnicodeData.txt file. That file does not describe the Unicode standard - it is just a data file, one of the two files required to implement the official mapping as described in section 3.13 of the Unicode standard version 4.0. That section actually does specify "Simple Casing" as opposed to the "Full Casing", however both are still required to use the many<->many codepoint mappings from SpecialCasing.txt. The Simple version refers only to lack of context-sensitive special cases. > For my applications, the case mappings defined in the draft are plenty > useful---they're sure useful well beyond ASCII. "Useful in some circumstances" is not grounds for tying Scheme to a 90%, non-standardized solution. The idea of ASCII-only mappings was suggested for the simple fact that they are well-defined, and required for many computer formats and protocols. If R6RS doesn't provide them, every Scheme will in some form or another, so it's better to standardize them. Call them ascii-char-ci=? etc. if the specificity bothers you. Another possibility is to define case operations as being required to support ASCII, with any Unicode support beyond that purely optional. -- Alex