From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Neil Jerram Newsgroups: gmane.lisp.guile.devel Subject: Re: [PATCH] SRFI-34, SRFI-60 and core bindings Date: Wed, 28 Dec 2005 20:14:35 +0000 Message-ID: <87bqz1j7x0.fsf@ossau.uklinux.net> References: <87zmp4mj1f.fsf@laas.fr> <871x0p4xpf.fsf@zagadka.de> <87r78pxln8.fsf@laas.fr> <87u0dcu0g7.fsf@zagadka.de> <878xuougt4.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 1135801080 365 80.91.229.2 (28 Dec 2005 20:18:00 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 28 Dec 2005 20:18:00 +0000 (UTC) Cc: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Wed Dec 28 21:17:57 2005 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 1Erhk4-0000UB-1S for guile-devel@m.gmane.org; Wed, 28 Dec 2005 21:17:48 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Erhke-0008Es-Fs for guile-devel@m.gmane.org; Wed, 28 Dec 2005 15:18:24 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Erhk6-00085a-U8 for guile-devel@gnu.org; Wed, 28 Dec 2005 15:17:51 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Erhk4-00084Y-Vg for guile-devel@gnu.org; Wed, 28 Dec 2005 15:17:50 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Erhk4-00084O-Jf for guile-devel@gnu.org; Wed, 28 Dec 2005 15:17:48 -0500 Original-Received: from [80.84.72.33] (helo=mail3.uklinux.net) by monty-python.gnu.org with esmtp (Exim 4.34) id 1ErhkI-00016P-D6 for guile-devel@gnu.org; Wed, 28 Dec 2005 15:18:02 -0500 Original-Received: from laruns (host86-129-132-201.range86-129.btcentralplus.com [86.129.132.201]) by mail3.uklinux.net (Postfix) with ESMTP id CD8F8409FB8; Wed, 28 Dec 2005 20:16:24 +0000 (UTC) Original-Received: from laruns (laruns [127.0.0.1]) by laruns (Postfix) with ESMTP id 3933F6F717; Wed, 28 Dec 2005 20:14:35 +0000 (GMT) Original-To: Marius Vollmer In-Reply-To: <878xuougt4.fsf@laas.fr> ( =?iso-8859-1?q?Ludovic_Court=E8s's_message_of?= "Wed, 14 Dec 2005 11:13:59 +0100") User-Agent: Gnus/5.1007 (Gnus v5.10.7) 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:5557 Archived-At: ludovic.courtes@laas.fr (Ludovic Court=E8s) writes: > Marius Vollmer writes: > >> Often, the user of a module also knows that everything is alright and >> wants to surpress the warning. (That's where you come in, >> Ludovic. :-) The user can only do that by giving parameters to >> use-modules or its own define-module. He should not go and add a >> #:replace to the exporting module. The only ways to do avoid the >> duplicate warning for a module user currently are to rename the >> bindings on import, or to use an explicit #:duplicates handler. >> (Right? Anything else?) > > I find this use of duplicate binding policies quite circumvoluted and > unclean for that matter. I agree with Ludovic. What we have now seems seriously screwy, and I'm sorry I didn't pay attention when this was first discussed and implemented. (duplicate-handlers is a module??!! And there was me thinking we already had quite a good class system in Guile.) 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. 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'm not saying that it's bad that users of the module suddenly get a warning in this situation; rather that it's wrong that the only (practical) way to fix the warning is to update the _module_'s code. (IMO using duplicate-handlers is far too heavyweight to be practical.) 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. Am I missing something? I can't see any good arguments for the current interface. Regards, Neil _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel