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: Mon, 24 Oct 2005 10:10:32 +0200 Organization: LAAS-CNRS Message-ID: <871x2bjpxj.fsf@laas.fr> References: <87zmp4mj1f.fsf@laas.fr> <87sluw9dqa.fsf@zip.com.au> <87fyqvgvd1.fsf@laas.fr> <87u0fabo9p.fsf@zip.com.au> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1130147227 5813 80.91.229.2 (24 Oct 2005 09:47:07 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 24 Oct 2005 09:47:07 +0000 (UTC) Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Mon Oct 24 11:46:56 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1ETyt2-0003uw-Es for guile-devel@m.gmane.org; Mon, 24 Oct 2005 11:45:00 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ETyt1-0001nA-JU for guile-devel@m.gmane.org; Mon, 24 Oct 2005 05:44:59 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1ETxTY-0000Em-6w for guile-devel@gnu.org; Mon, 24 Oct 2005 04:14:40 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1ETxTT-0000E6-6v for guile-devel@gnu.org; Mon, 24 Oct 2005 04:14:32 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ETxTP-0000DU-6E for guile-devel@gnu.org; Mon, 24 Oct 2005 04:14:28 -0400 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 1ETxTO-0007PO-OG for guile-devel@gnu.org; Mon, 24 Oct 2005 04:14:27 -0400 Original-Received: by laas.laas.fr (8.13.1/8.13.4) with SMTP id j9O8EOlx003814; Mon, 24 Oct 2005 10:14:25 +0200 (CEST) Original-To: guile-devel@gnu.org X-URL: http://www.laas.fr/~lcourtes/ X-Revolutionary-Date: 3 Brumaire 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: guile-devel@gnu.org In-Reply-To: <87u0fabo9p.fsf@zip.com.au> (Kevin Ryde's message of "Sat, 22 Oct 2005 06:36:50 +1000") User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.4 (gnu/linux) X-Spam-Score: 0.496 () MAILTO_TO_SPAM_ADDR 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:5352 Archived-At: Hi, Kevin Ryde writes: > Yes, I'm talking about the module user too, the module user loses some > core bindings. > >> This is exactly the behavior users may expect. > > If you don't know about the clashes/replacements then you're likely to > be unpleasantly surprised to see core stuff suddenly move under your > feet. But a way to acknowledge that in the use-modules might be nice. My opinion about this is that it is a matter of documentation. That is, you don't want core bindings to get overloaded in unexpected ways. However, in some cases, you do know that a given module redefines various core bindings, and you do know that you *want* this. The manual clearly documents the binding conflicts for the SRFI modules we're talking about. I'd say it is the user's responsibility to make sure they know what they're doing. ;-) As I tried to explain in the doc, `#:replace' is really a way for the module developer to give a *hint* to the module user. By default, this hint will be obeyed by the module user. However, the user still has the opportunity to not take this hint into account by choosing a different chain of duplicate binding handlers. Now, if that hint is not provided by the modules in question and you want to tell the module system that you *know* what you're doing (to get rid of the warning message), then there is no clean way to do it. Of course, you can choose the `last', `first', or whatever duplicate binding handler that makes the warning message vanish (this is what people sometimes do currently). But that does not qualify as a clean solution. Thanks, Ludovic. _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel