[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: case mappings
Thomas Bushnell BSG <tb@xxxxxxxxxx> writes:
> Michael Sperber <sperber@xxxxxxxxxxxxxxxxxxxxxxxxxxx> writes:
>> For my applications, the case mappings defined in the draft are plenty
>> useful---they're sure useful well beyond ASCII. Restricting them to
>> ASCII would make them very significantly less useful to me. (What
>> with me being a German an all. And BTW, no, the eszet issue is not
>> usually a problem in practice---it sure doesn't keep the case mappings
>> from being useful.)
> Your applications are useful *for German* maybe.... but that doesn't
> mean that the code you write, thinking only of your case, will work
> where the locale is different and more serious problems arise.
I have expressed myself poorly: If I want my code to behave in a
locale-specific way, then I'll use procedures that respect locale.
Ditto for full string-to-string case-mapping in a locale-independent
manner. In other words, I need to indicate in my source code what I
want. Sometimes I want exactly the case mapping the current SRFI
draft has---I *don't* want any of the others.
> You are quite right that this is a hard problem. [...]
> Case mapping is not a character-to-character function, it is a
> string-to-string function.
> Once you learn that, everything else becomes trivial.
I don't know what you think will become trivial. Not much I can think
of. Even implementing the UnicodeDate.txt case mappings is not
trivial to do efficiently---which is why we'll provide a reference
implementation for those pretty soon.
> Scheme has a system for numeric procedures that works automagically
> for systems that want really fancy stuff.
You're talking to the wrong person here: The fanciness in the R5RS
arithmetic often does the wrong thing. Which is why people need to be
able to indicate what they want. So this is a pretty good parallel to
the case mapping.
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla