Hi,

I have come up with an `(ice-9 i18n)' module that contains
locale-dependent text collation functions and also character case
mapping and functions to read numbers.  There would be a lot more things
to add, like `strfmon ()', but I think that's a good start.

Here are the key points that may deserve further discussion:

1. Use of a glibc-specific reentrant API (the `_l' functions).  As I
   mentioned in my previous post, the idea here is to provide the option
   to pass locale information as an additional argument, as in:

     (string-locale<? "hello" "world" my-locale)

   That last argument may be omitted, in which case the current process
   locale is used (and the "regular" C function is used behind the
   scenes).  Note that in cases where this optional argument is not
   used, the implementation is exactly the same on both GNU and non-GNU
   systems.

   For non-GNU systems, I implemented this (dealing with the LOCALE
   argument) by serializing calls to `setlocale', and performing as many
   `setlocale' calls as needed to install the locale specified by this
   third argument (details in `i18n.c' below).  This is not efficient
   nor very elegant, but at least, it provides users with the same
   semantics across all systems.

   There's one difference, though, between the behavior on GNU and
   non-GNU systems: on GNU, passing a wrong locale name to `make-locale'
   immediately yields an exception, while on non-GNU that exception will
   only be raised when the locale object is actually used.

   Kevin mentioned the argument in glibc's <locale.h> stating that the
   `locale_t' API was a "proof-of-concept".  It seems, however, that
   it's built to stay [0].

2. Kevin said: "I wonder if the unicode of r6rs might make the
   implementation difficult later."  When we support Unicode, `i18n.c'
   "just" has to be changed to use the wide-character variants of the
   various functions (e.g., `wstrcoll' instead of `strcoll', etc.).  So
   I don't think there's much to worry about here.

3. I've put those functions in `(ice-9 i18n)' but they are actually
   implemented in C so `i18n.scm' simply `dynamic-link's a new library,
   `libguile-i18n-v0', that is compiled from within the `libguile'
   directory.

   The rationale for doing it was the following:

   * Reduce startup time.  The approach that consists in initializing
     _everything_ at startup is not scalable.

   * Optionally, reduce memory footprint when the module is not used,
     although that's arguably not a major concern.

   On IRC, Rob identified a number of issues with this approach:

   * It would be the first `ice-9' module that does a `dynamic-link', so
     we may want to think twice before doing it.

   * The C programmer willing to use those functions would have to link
     against `libguile-i18n' additionally.

   There's another (small) issue:

   * The online help is a bit confused because the doc of the i18n.c
     functions is include in libguile's `guile-procedure.txt'.  Thus,
     `(help make-locale)' always works, even when `(ice-9 i18n)' is not
     loaded.

Personally, I'm not worried about issues (1) and (2).  As for item (3),
I'd be tempted to leave the thing in a separate shared library.  While I
agree that this practically precludes use of those functions by C
programmers (as is the case for those SRFIs that are implemented in C),
I believe that this module is more targeted towards Scheme programmers
and, consequently, I see more value in keeping the module's code in a
separate shared lib than in providing access to the C functions.

What do you think?

Thanks,
Ludovic.

[0] http://sources.redhat.com/ml/libc-alpha/2006-09/msg00033.html