Comparison with Forth equivalent

[Darren Bane <dbane@xxxxxxxxxxxxxxxx>]

It's quiet in here ...</LURK>  Sorry, this is longer than I intended.

I thought it would be interesting to compare your SRFI with the Forth 
equivalent - both it and Scheme are fairly minimal languages, and just a 
little outside the mainstream.  The Forth standards proposal is at the 
end of http://www.mpeltd.demon.co.uk/arena.htm#papers

I'll try to limit this to the SRFI's scope (e.g. no wide characters).


1.  current-locale:
------------------
Instead of returning a list, Forth provides two words get-language and 
get-country.  These deal with the ISO codes (e.g. en, de, us, ie), 
apparently in the equivalent of symbol form (words).

Note that set-language and set-country are provided also.  Arguably, 
this is nice for symmetry, but I think it's better to leave locale 
selection up to the user (e.g. using environment variables).


2.  declare-bundle and localized-template:
-----------------------------------------
Instead of a high-level data structure, Forth just defines a method to 
store references to language-dependent strings in memory - L".  Thus its 
dictionaries have string keys like GNU gettext, rather than the (int, 
int) tuples of XPG4 or your own '(package msg-sym).  Presumably then 
there is an auxiliary file like an XPG4 message catalogue which holds 
the text for different languages - this is left up to the implementation.


Interestingly, they include a simple string macro expander as an 
integral part, similar to SRFI-28.

----------

Overall, well done on actually bothering to write an SRFI.  I had been 
daydreaming about doing something similar for months.  But now, here's 
my feedback:


*  I'm worried about performance and/or fitting in with the host OS.  I 
know almost all software runs "fast enough", but XPG4 implementations 
can go to some lengths (on-disk hashes mmapped into RAM) for speed.  I 
would guess that this isn't for nothing.

Even if nobody does, I'd like to allow implementors the latitude to do 
something like this, or better, just interface to the system libraries 
with an FFI.  So I'd suggest defining declare-bundle as a sublanguage, 
somewhat like SRFI-7.  The sample implementation could remain the same 
and you could just load these files, but at least people would then be 
able to use a different scheme, say generating a message catalogue from 
the source.

All this really needs is a statement saying that declare-bundle needn't 
necessarily be full Scheme and that you should put the declare-bundles 
for each language in a separate source file.

I'd almost consider the ability to implement this SRFI in terms of the 
native OS facilities (which for me is XPG4) a requirement.


*  localized-template is a lot of typing.  For comparison, one Forth 
equivalent of

   (display (format (localized-template 'package 'hello-msg))) is
   L" Hello World!" LOCALE@ PAD 84 SUBSTITUTE TYPE CR

Hmm.  Maybe you should just ignore that.


*  One advantage of using strings as keys into the dictionary instead of 
integers/symbols is that the string can be the default message if no 
local translation is found.  XPG4 doesn't do this, and has to have 
another parameter to catgets for the default (although you could always 
just pass NULL).

However, having said that, I prefer things the way they are.


Just thought I'd get the ball rolling ...


----------

  REFERENCES

ANS Forth Internationalisation proposal 
(http://www.mpeltd.demon.co.uk/arena/i18n.propose.v7.PDF)
gencat(1) 
(http://www.openbsd.org/cgi-bin/man.cgi?query=gencat&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html)
catopen(3) 
(http://www.openbsd.org/cgi-bin/man.cgi?query=catopen&sektion=3&apropos=0&manpath=OpenBSD+Current)
catgets(3) 
(http://www.openbsd.org/cgi-bin/man.cgi?query=catgets&sektion=3&apropos=0&manpath=OpenBSD+Current)
catclose(3) 
(http://www.openbsd.org/cgi-bin/man.cgi?query=catclose&sektion=3&apropos=0&manpath=OpenBSD+Current)
gettext(3) (http://www.gnu.org/manual/gettext/html_chapter/gettext_toc.html)
--
Darren Bane