From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: ludovic.courtes@laas.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=) Newsgroups: gmane.lisp.guile.devel Subject: Re: Text collation Date: Wed, 25 Oct 2006 10:16:10 +0200 Organization: LAAS-CNRS Message-ID: <87slhclsj9.fsf@laas.fr> References: <877j00cirs.fsf@laas.fr> <87hcz3mqhr.fsf@zip.com.au> <87r6x0qjyy.fsf@laas.fr> <877iyrbxj7.fsf@raven.defaultvalue.org> <87wt6rxy6z.fsf@laas.fr> <87ac3m2joj.fsf@raven.defaultvalue.org> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1161764401 11621 80.91.229.2 (25 Oct 2006 08:20:01 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 25 Oct 2006 08:20:01 +0000 (UTC) Cc: Guile-Devel Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Wed Oct 25 10:19:57 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 1GcdzO-000128-5P for guile-devel@m.gmane.org; Wed, 25 Oct 2006 10:19:54 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GcdzN-00032j-BI for guile-devel@m.gmane.org; Wed, 25 Oct 2006 04:19:53 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GcdxV-0002KP-9q for guile-devel@gnu.org; Wed, 25 Oct 2006 04:17:57 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GcdxT-0002J8-P2 for guile-devel@gnu.org; Wed, 25 Oct 2006 04:17:56 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GcdxT-0002Iv-3w for guile-devel@gnu.org; Wed, 25 Oct 2006 04:17:55 -0400 Original-Received: from [140.93.0.15] (helo=laas.laas.fr) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1GcdxS-0008Q1-Oq for guile-devel@gnu.org; Wed, 25 Oct 2006 04:17:55 -0400 Original-Received: by laas.laas.fr (8.13.7/8.13.4) with SMTP id k9P8HYgf019441; Wed, 25 Oct 2006 10:17:41 +0200 (CEST) Original-To: Rob Browning X-URL: http://www.laas.fr/~lcourtes/ X-Revolutionary-Date: 4 Brumaire an 215 de la =?iso-8859-1?Q?R=E9volution?= X-PGP-Key-ID: 0xEB1F5364 X-PGP-Key: http://www.laas.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 821D 815D 902A 7EAB 5CEE D120 7FBA 3D4F EB1F 5364 X-OS: powerpc-unknown-linux-gnu Mail-Followup-To: Rob Browning , Guile-Devel In-Reply-To: <87ac3m2joj.fsf@raven.defaultvalue.org> (Rob Browning's message of "Tue, 24 Oct 2006 01:37:48 -0700") User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) X-Spam-Score: 0 () X-Scanned-By: MIMEDefang at CNRS-LAAS 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:6175 Archived-At: Hi, Rob Browning writes: > (BTW, does documentation snarfing work right for C functions in > libraries outside libguile? If not, then that's just a bug.) No, it doesn't work. In the latest `guile-reader', I have a couple of modules that do (part of) what the Awk script in `libguile' does: parsing the output of `cpp -DSCM_MAGIC_SNARF'. I'd be in favor of integrating such an approach in Guile core eventually. >> The issue, IMO, is that this is not very "scalable" either: we still >> end up adding one function call in `scm_i_init_guile ()' that >> systematically gets in the way. > > I'm actually not sure which (of the discussed approaches) I think is > best. I suppose first we'd need to consider the extent to which we > want to move toward a more modular ice-9 (more modular core), and then > determine how we might want to implement that modularity. Personally, I would like Guile "core" to be much more modular than what it is now. I believe many things in what we call "Guile core" are there just because we want them to be part of the "standard Guile library", but they certainly to not comprise the "core" or "kernel" of Guile. For instance, I believe the Gettext-related functions ought to be distributed with Guile core but as a separate module. Same for SRFI-1[43]. Not to mention the bits and pieces that are in `boot-9' and that happen to be visible to everyone. ;-) Basically, the logical separation among the R5.91RS standard libraries has a level of granularity that looks appropriate to me. Now, whether each module should load its own shared library is a different issue. This may depend on the module characteristics: size, usefulness, C programmability. We also have to find a balance between lazy initialization (with `dynamic-link') and systematic initialization. Getting back to `(ice-9 i18n)': I'm strongly in favor of keeping this as a module; I am more inclined to having it in a separate shared library (because it's not useful to everyone) but I wouldn't mind having it in `libguile.so'. Thanks, Ludovic. _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel