From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Kevin Ryde Newsgroups: gmane.lisp.guile.devel Subject: Re: More i18n Date: Tue, 23 Jan 2007 11:46:18 +1100 Message-ID: <871wlmwox1.fsf@zip.com.au> References: <877iwzokpz.fsf@chbouib.org> <87vekg2a7a.fsf@zip.com.au> <878xg2tzjz.fsf@chbouib.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: sea.gmane.org 1169513270 12866 80.91.229.12 (23 Jan 2007 00:47:50 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 23 Jan 2007 00:47:50 +0000 (UTC) Cc: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Tue Jan 23 01:47:40 2007 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1H99p3-0007kd-FW for guile-devel@m.gmane.org; Tue, 23 Jan 2007 01:47:37 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1H99p3-0005fq-0t for guile-devel@m.gmane.org; Mon, 22 Jan 2007 19:47:37 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1H99o4-0005Ff-IL for guile-devel@gnu.org; Mon, 22 Jan 2007 19:46:37 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1H99o3-0005EN-4W for guile-devel@gnu.org; Mon, 22 Jan 2007 19:46:35 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1H99o3-0005EB-2L for guile-devel@gnu.org; Mon, 22 Jan 2007 19:46:35 -0500 Original-Received: from [61.8.2.231] (helo=mailout2.pacific.net.au) by monty-python.gnu.org with esmtp (Exim 4.52) id 1H99o2-00059U-7i for guile-devel@gnu.org; Mon, 22 Jan 2007 19:46:34 -0500 Original-Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.2.162]) by mailout2.pacific.net.au (Postfix) with ESMTP id 31F256E232; Tue, 23 Jan 2007 11:46:30 +1100 (EST) Original-Received: from localhost (ppp2286.dyn.pacific.net.au [61.8.34.134]) by mailproxy1.pacific.net.au (Postfix) with ESMTP id F17278C37; Tue, 23 Jan 2007 11:46:30 +1100 (EST) Original-Received: from gg by localhost with local (Exim 4.63) (envelope-from ) id 1H99no-00005x-L9; Tue, 23 Jan 2007 11:46:20 +1100 Original-To: ludo@chbouib.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) Mail-Copies-To: never In-Reply-To: <878xg2tzjz.fsf@chbouib.org> (Ludovic =?iso-8859-1?Q?Court=E8?= =?iso-8859-1?Q?s's?= message of "Tue, 16 Jan 2007 22:46:40 +0100") User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:6470 Archived-At: ludo@chbouib.org (Ludovic Court=E8s) writes: > > 4. No attempt is made to convert to a different encoding the strings > returned by `nl_langinfo ()'. Good. > 5. High-level procedures for locale-dependent number output are > provided, namely `number->locale-string' and > `monetary-amount->locale-string'. Both of them are implemented in > Scheme (which is relieving, really ;-)). See how much nicer it is :-). > +* i18n Introduction:: Introduction to Guile's i18n support. "i18n" is a horrible geek-ish abbreviation, much better written in full in the manual. > +@deffn {Scheme Procedure} make-locale category-list locale-name [base-lo= cale] Just a single category too will be good there. Just LC_ALL is probably be almost always what's wanted. > +@defvr {Scheme Variable} %global-locale I'm worried if that should be a variable, rather than a function. > These procedures allow to account for these differences. Slightly ungrammatical there (I'm sure it reads better in french :-). > +This function is based on the C library's @code{strtod} function Not any more? Or just in a broadly similar style? > +@deffn {Scheme Procedure} locale-era [locale] > +@deffnx {Scheme Procedure} locale-era-year [locale] > +These functions return, respectively, the era and the year of the > +relevant era used in @var{locale} or the current locale. Most locales > +do not define this value. What do the functions do in that case (ie. no era)? Will my computer explode? > +@deffn {Scheme Procedure} locale-digit-grouping [locale] > +Return a (potentially circular) list denoting how digits You could rearrange the words to get "list of integers" somewhere near the start, for maximum clarity. > +(define us (make-locale (list LC_MONETARY) "en_US")) That's an example of where I think having to say "list" is a bit pesky. Just (make-locale LC_MONETARY ...) will be good. > +(locale-currency-symbol #f us) > +@result{} "-$" Is it actually "-$" there, or just "$"? > +@deffn {Scheme Procedure} locale-yes-regexp [locale] > +@deffnx {Scheme Procedure} locale-no-regexp [locale] These aren't gnu extensions are they? > +Example uses of some of these functions are the implementation of the > +@code{number->locale-string} and @code{monetary-amount->locale-string} > +procedures (@pxref{Number Input and Output}), as well as that the > +SRFI-19 date and time convertion to/from strings (@pxref{SRFI-19}). I wouldn't worry about that bit. A nice broad introduction at the start of the node should be ok. > +(define (locale-encoding . locale) > + (apply nl-langinfo CODESET locale)) I think you should implement almost all these basic bits in C, and not have a big nl-langinfo. It'll be easier for a future localeconv conditionals, or some of the DOS apis. It'll also be smaller and faster to load and run. > +(define-vector-langinfo-mapping locale-day-short > + (ABDAY_1 ABDAY_2 ABDAY_3 ABDAY_4 ABDAY_5 ABDAY_6 ABDAY_7) > + ("Sun" "Mon" "Tue" "Wed" "Thu" "Fri" "Sat")) These in C too I think. > number formatting ... > > + (let loop ((index (- strlen 1)) > + (grouping grouping) > + (since-separator 0) > + (result "")) Consider breaking out of the loop when grouping is null, and in any case going group by group instead of character by character. The result could be built as a list of strings to be concatenated at the end too (string-concatenate/reverse or whatever it is). > ;;; Local Variables: > ;;; coding: latin-1 The fallbacks are all ascii aren't they? > nl-langinfo ... > + However, `scm_from_locale_string', > + which expects a Latin-1 string, won't be able to make much sense o= f the > + returned string. No need to be too worried about that. scm_from_locale_string is little more than a placeholder until there's a notion of coding within strings. Almost every call to it will have to be reviewed for whether it's actually the locale charset, another charset, or binary bytes. > nl-langinfo ... > + switch (c_item) > + { > + case GROUPING: > + case MON_GROUPING: Special cases like that will be cleaner in their own function I think. > + scm_syserror_msg (FUNC_NAME, > + "`language-information' not supported on your system", Still `language-information'? I expect if each `locale-foo' is a separate func then they should be able to return sensible defaults, avoiding such an error. > +(define (priv:vector-find needle haystack-ref haystack-len comparator) Does that still search a vector? Could rename it if not. Whatever it does now, a func call int range searcher or whatever. > +;;; > +;;; `nl-langinfo' > +;;; Could make a separate section for each func exercised there (irrespective what they do internally). Apart from that it all looks good. _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel