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: [PATCH] SRFI-34, SRFI-60 and core bindings Date: Tue, 03 Jan 2006 11:06:15 +0100 Organization: LAAS-CNRS Message-ID: <87mzid7hig.fsf@laas.fr> References: <87zmp4mj1f.fsf@laas.fr> <871x0p4xpf.fsf@zagadka.de> <87r78pxln8.fsf@laas.fr> <87u0dcu0g7.fsf@zagadka.de> <878xuougt4.fsf@laas.fr> <87bqz1j7x0.fsf@ossau.uklinux.net> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1136290327 7788 80.91.229.2 (3 Jan 2006 12:12:07 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 3 Jan 2006 12:12:07 +0000 (UTC) Cc: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Tue Jan 03 13:12:03 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 1Etl1H-0006hk-1i for guile-devel@m.gmane.org; Tue, 03 Jan 2006 13:12:03 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Etl2t-0000Ui-Fj for guile-devel@m.gmane.org; Tue, 03 Jan 2006 07:13:43 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Etj6n-0007ZV-EL for guile-devel@gnu.org; Tue, 03 Jan 2006 05:09:40 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Etj5N-0006f6-U6 for guile-devel@gnu.org; Tue, 03 Jan 2006 05:08:18 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Etj5F-0006Zs-P5 for guile-devel@gnu.org; Tue, 03 Jan 2006 05:08:02 -0500 Original-Received: from [140.93.0.15] (helo=laas.laas.fr) by monty-python.gnu.org with esmtp (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.34) id 1Etj6S-0005EV-8p for guile-devel@gnu.org; Tue, 03 Jan 2006 05:09:16 -0500 Original-Received: by laas.laas.fr (8.13.1/8.13.4) with SMTP id k03A6GT1022563; Tue, 3 Jan 2006 11:06:18 +0100 (CET) Original-To: Neil Jerram X-URL: http://www.laas.fr/~lcourtes/ X-Revolutionary-Date: 14 =?iso-8859-1?Q?Niv=F4se?= an 214 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: Neil Jerram , Marius Vollmer , guile-devel@gnu.org In-Reply-To: <87bqz1j7x0.fsf@ossau.uklinux.net> (Neil Jerram's message of "Wed, 28 Dec 2005 20:14:35 +0000") User-Agent: Gnus/5.110004 (No Gnus v0.4) 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:5572 Archived-At: Hi, Neil Jerram writes: > It seems completely wrong for the defining module to be responsible > for guessing which of its bindings might have the same name as other > bindings in the wide world outside that module. I disagree. The set of core bindings is not supposed to be very large, and it's not that hard to see whether you're overriding a core binding. Given that, that doesn't seem too much of a burden for the defining module to explicitly warn its users (via `#:replace') of its intention to override a core binding. > In particular, this gives the absurd situation where a module can be > 100% correct one day, then we add a new function to core Guile, and > that same module now becomes incorrect. I don't think this is an issue, practically. Theoretically, that should _not_ be an issue because we should try to keep the set of core bindings as small as possible IMO. > It strikes me as a much more reasonable proposition for the _using_ > module to be responsible for the bindings that it imports, and the > fact that we already have #:select, #:hide and #:renamer is in line > with this. So it seems obvious that #:replace should really be > another option for use-modules and #:use-module, _not_ for > define-module. In a way, this is already what happens: 1. The defining module provides a /hint/ about purposefully overridden bindings, via a `#:replace' option to `define-module'; 2. The using module is /free/ to take such hints into account; by default, it will do so, because it will be using the `replace' duplicate binding handling policy (see the recent additions to the manual in HEAD). My conclusion is that the current interface is actually quite good. It just needs to be well documented. :-) Thanks, and best wishes! Ludovic. _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel