From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Rob Browning Newsgroups: gmane.lisp.guile.devel Subject: Re: Text collation Date: Sun, 22 Oct 2006 19:01:32 -0700 Message-ID: <877iyrbxj7.fsf@raven.defaultvalue.org> References: <877j00cirs.fsf@laas.fr> <87hcz3mqhr.fsf@zip.com.au> <87r6x0qjyy.fsf@laas.fr> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: sea.gmane.org 1161568947 8274 80.91.229.2 (23 Oct 2006 02:02:27 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 23 Oct 2006 02:02:27 +0000 (UTC) Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Mon Oct 23 04:02:21 2006 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1Gbp8F-0001ar-2n for guile-devel@m.gmane.org; Mon, 23 Oct 2006 04:01:42 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Gbp8E-0002vc-NK for guile-devel@m.gmane.org; Sun, 22 Oct 2006 22:01:38 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Gbp8B-0002vG-Kh for guile-devel@gnu.org; Sun, 22 Oct 2006 22:01:35 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Gbp8B-0002ur-1k for guile-devel@gnu.org; Sun, 22 Oct 2006 22:01:35 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Gbp8A-0002uo-PS for guile-devel@gnu.org; Sun, 22 Oct 2006 22:01:34 -0400 Original-Received: from [70.85.129.156] (helo=defaultvalue.org) by monty-python.gnu.org with esmtp (Exim 4.52) id 1Gbp8A-0007SE-50 for guile-devel@gnu.org; Sun, 22 Oct 2006 22:01:34 -0400 Original-Received: from omen.defaultvalue.org (localhost [127.0.0.1]) by defaultvalue.org (Postfix) with ESMTP id 8390190DDA for ; Sun, 22 Oct 2006 19:01:33 -0700 (PDT) Original-Received: from raven.defaultvalue.org (raven.defaultvalue.org [192.168.1.7]) by omen.defaultvalue.org (Postfix) with ESMTP id 20F6434004 for ; Sun, 22 Oct 2006 19:01:33 -0700 (PDT) Original-Received: by raven.defaultvalue.org (Postfix, from userid 1000) id 05043355171; Sun, 22 Oct 2006 19:01:32 -0700 (PDT) Original-To: Guile-Devel In-Reply-To: <87r6x0qjyy.fsf@laas.fr> (Ludovic =?iso-8859-1?Q?Court=E8s's?= message of "Sun, 22 Oct 2006 20:33:09 +0200") 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:6172 Archived-At: ludovic.courtes@laas.fr (Ludovic Court=E8s) writes: > 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. Yes, the main question is to what extent we want people coding in C to have to link aginst libraries other than -lguile. Of course, this is already the case for some of the SRFIs. > 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. Perhaps that's something we'll eventually want to fix in the documentation system, but a really simple approach might be to just mention the required module in the documentation for each function. > 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) Actually, if I understand you correctly, this isn't the case. The SRFIs (which provide C interfaces) are definitely intended for use by C programmers. The programmers just have to make sure to include the correct -lguile-srfi-* for the SRFI in question. Although I'm not sure it's a great idea, one other possibility would be to put the C code in libguile, and to provide a C init function, called from init.c, that doesn't do anything more than publish a scheme-side init function that can handle the full initialization later. Then the startup process should be relatively unaffected, and ice-9/i18n.scm would just do something like this: (define-module (ice-9 i18n) ...) (scm-init-i18n) This would avoid the need to make it possible to use dynamic-link for items that are already in libguile. Of course, whether or not the approach is a good idea is a different question. --=20 Rob Browning rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu GPG starting 2002-11-03 =3D 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 7= 3A4 _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel