unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: ludovic.courtes@laas.fr (Ludovic Courtès)
Cc: guile-devel@gnu.org
Subject: Re: [PATCH] SRFI-34, SRFI-60 and core bindings
Date: Wed, 14 Dec 2005 11:13:59 +0100	[thread overview]
Message-ID: <878xuougt4.fsf@laas.fr> (raw)
In-Reply-To: <87u0dcu0g7.fsf@zagadka.de> (Marius Vollmer's message of "Tue, 13 Dec 2005 23:55:04 +0200")

Marius Vollmer <mvo@zagadka.de> writes:

> When using #:replace, the exporting module is making the promise that
> the warning can be surpressed because everything is alright.  It can
> only do that if the replacing binding is compatible with what it
> replaces.

So I think we disagree.  ;-)  Basically, I'm saying that `#:replace' is
alright when the module /purposefully/ overrides and binding and is
documented to do so, while you say that it should be used only when a
module /compatibly/ overrides a binding.

I still think that one never types `(use-modules (srfi srfi-60))'
inadvertently, which supports the `purposefully' vision.  IOW, the
"common case" (and this is debatable) is that you _want_ `bit-count' to
be overridden when you type this in.  And we want to optimize for the
common case.

In any case, the documentation will have to be updated to whatever
vision you think is right.

> 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.

> Hmm, I think current usage is in line with what I described above.
> Right?

Right, within Guile.  Outside, current usage may be inexistent because
it was not documented.

Thanks,
Ludovic.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel


  reply	other threads:[~2005-12-14 10:13 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-10-20 13:09 [PATCH] SRFI-34, SRFI-60 and core bindings Ludovic Courtès
2005-10-20 19:42 ` Kevin Ryde
2005-10-21  7:52   ` Ludovic Courtès
2005-10-21 20:36     ` Kevin Ryde
2005-10-24  8:10       ` Ludovic Courtès
2005-12-06 23:23 ` Marius Vollmer
2005-12-07 10:10   ` Ludovic Courtès
2005-12-13 21:55     ` Marius Vollmer
2005-12-14 10:13       ` Ludovic Courtès [this message]
2005-12-28 20:14         ` Neil Jerram
2006-01-03 10:06           ` Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=878xuougt4.fsf@laas.fr \
    --to=ludovic.courtes@laas.fr \
    --cc=guile-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).