This page is part of the web mail archives of SRFI 13 from before July 7th, 2015. The new archives for SRFI 13 contain all messages, not just those from before July 7th, 2015.
Sergei Egorov[SMTP:esl@xxxxxxxxxxxxxxx] wrote:
> And I am not against char-upcase and char-downcase as long as their
definition
> is limited to ASCII; otherwise you will have to ignore three problems
> mentioned in the Unicode book: uppercase I may map to either i or
dotless i
CHAR-{UP,DOWN}CASE can work correctly as-is in Unicode as long as the
program is working with decomposed character input - the most common
case.
The challenge of Turkish casing is a separate issue, one which this SRFI
surfs around by alluding to the global environment. I agree with you
that it's more like collation. Probably to be addressed by a
WITH-LOCALE form or CALL-WITH-LOCALE procedure in some future proposal.
> and explicitly
> specify that string>? and other comparisons are based on
> mechanical code-point comparison that might not correspond
"Explicitly" ... "are based" is too strong. For this, too, the current
Turkish compromise (in your words) makes the library "reasonably useful"
and "simple to implement" (at least where you have collation callouts
available from the OS). I've never found a use for non-locale-sensitive
string ordering. So please soften this to "may be based."
Ben