Hi,

Guile doesn't provide any locale-dependent string comparison primitive.
`string<?' et al., from SRFI-13 (also found in R5.91RS), are required to
be locale-independent:

  These procedures are the lexicographic extensions to strings of the
  corresponding orderings on characters. For example, string< is the
  lexicographic ordering on strings induced by the ordering char<? on
  characters.

  [...]

  Comparison is simply done on individual code-points of the
  string. True text collation is not handled by this SRFI.

R5.91RS, about `char<?' et al., adds:

  These procedures impose a total ordering on the set of characters
  according to their scalar values.

Thus, for proper locale-dependent "text collation", we need a separate
API.  The patch below provides preliminary support for this.  Here is a
sample session showing how the API can be used:

  guile> (define l (make-locale LC_COLLATE_MASK "fr_FR"))
  guile> l
  #<locale 300a74d0>
  guile> (string-locale<? "été" "hiver") ;; using the "C" locale
  #f
  guile> (string-locale<? "été" "hiver" l)
  #t
  guile> (char-locale<? #\é #\h)         ;; using the "C" locale
  #f
  guile> (char-locale<? #\é #\h l)
  #t
  guile> (setlocale LC_COLLATE "fr_FR")
  "fr_FR"
  guile> (string-locale<? "été" "hiver") ;; using the "fr_FR" locale
  #t

The cool thing is that it's a "clean" API in that the locale settings
can be passed explicitly as a third parameter.  The (potentially)
controversial part is that this wraps a non-standard GNU extension.

I don't think this should be seen as a problem, first because this GNU
extension can be emulated on non-GNU platforms by controlling
invocations of `setlocale' (via a mutex) and by using that to create
"critical locale sections" within the `-locale<?' functions:

  /* Save the current locale settings and install LOCALE_SETTINGS.  */
  scm_being_locked_locale_section (locale_settings);

  result = strcoll (c_s1, c_s2);
  /* ... */

  /* Restore the previous locale settings.  */
  scm_end_locked_locale_section ();

Emulation of the locale category mask that is passed to `make-locale'
may turn out to be quite inelegant, but it can be implemented in terms
of `setlocale ()' (as many calls as bits set in the mask).

Second, it is likely that this or a similar API will be adopted by OSes
and may eventually be standardized.  The C++ standard already includes a
similar locale API (ISO C++ 14882, see the `locale_classes.h' header
that ships with GCC).

The GNU C library also provides `strcasecmp_l ()' which would be nice to
have but since this would be hard or even impossible to "emulate" on
other platforms, it may be preferable not to include it at the moment.

If all this sounds like a reasonable plan to you, then I can implement
locked locale sections (for non-GNU platforms), augment the docs, and
eventually merge it in both 1.8 and HEAD.

Thanks,
Ludovic.

PS: I would be happier if this was part of an `(ice-9 i18n)' module but
    since it's already too late for `gettext', `bindtextdomain' and
    friends to go there, maybe we should just keep using the root
    module...