Thomas Bushnell BSG <xxxxxx@becket.net> writes:

> Michael Sperber <xxxxxx@informatik.uni-tuebingen.de> 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