Re: the discussion so far

["John.Cowan" <jcowan@xxxxxxxxxxxxxxxxx>]

bear scripsit:

> " These functions take a character argument and return a
> character result.  If the argument is an uppercase or
> titlecase letter, and there is a single letter which is its
> lowercase form, char-downcase returns that letter.  If the
> argument is a lowercase or titlecase letter, and there is a
> single letter which is its uppercase form, char-upcase
> returns that letter.  Otherwise, the character returned is
> the same as the argument.  Note that this is an incomplete
> approximation to case conversion; in general case mappings
> require the context of a string, both in arguments and in
> result.  See string-upcase and string-downcase for more
> general case conversion functions.  "

+1

This also induced me to realize that char-titlecase belongs here as well.

> and this language for string-upcase and string-downcase:
> 
> " These functions take a string argument argument and return
> a string as their result.  String-upcase converts a string
> to uppercase, and string-downcase converts a string to
> lowercase.  If an implementation supports locales, the case
> folding done by these functions will be according to the
> value of (current-locale). "

These do case mapping, not case folding.  I suggest this language:

" These functions take a string argument argument and return
a string as their result.  String-upcase converts a string
to uppercase, and string-downcase converts a string to
lowercase.  The result may or may not be the same length as
the argument."

There are only two locales for case mapping, Turkic and non-Turkic
(thanks to the unusual behavior of dotless-i and dotted-I in some
Turkic languages).  I'm not sure that a full locale mechanism should
be spec'ed just for that, though it will be needed for the UCA functions.

String-titlecase also belongs here: it maps the first character to
titlecase, and the rest to lowercase.

> string-UCA>?
> string-UCA>=?
> string-UCA=?
> string-UCA<=?
> string-UCA<?

I support these, but think they belong in a general i18n/l10n SRFI.
I will be happy to assist in creating such a SRFI.

-- 
MEET US AT POINT ORANGE AT MIDNIGHT BRING YOUR DUCK OR PREPARE TO FACE WUGGUMS
John Cowan   http://www.reutershealth.com   jcowan@xxxxxxxxxxxxxxxxx