From: Andy Wingo <wingo@pobox.com>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: Guile Devel <guile-devel@gnu.org>
Subject: Re: Re-exporting a replaced binding
Date: Sun, 05 Jan 2020 11:03:20 +0100 [thread overview]
Message-ID: <87woa6z0d3.fsf@pobox.com> (raw)
In-Reply-To: <87r20go0j9.fsf@inria.fr> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\=22\?\= \=\?utf-8\?Q\?'s\?\= message of "Fri, 03 Jan 2020 19:30:34 +0100")
On Fri 03 Jan 2020 19:30, Ludovic Courtès <ludo@gnu.org> writes:
> I’m not sure if this is an intended consequence of
> cf08dbdc189f0005cab6f2ec7b23ed9d150ec43d, so I thought I’d share this
> example of a practical effect:
>
> ludo@ribbon /tmp [env]$ cat x.scm
> (define-module (x)
> #:use-module (srfi srfi-1)
> #:re-export (delete))
> ludo@ribbon /tmp [env]$ cat y.scm
> (define-module (y)
> #:use-module (x))
>
> (pk 'delete delete)
> ludo@ribbon /tmp [env]$ guile -L . -c '(use-modules (y))'
> WARNING: (y): imported module (x) overrides core binding `delete'
>
> ;;; (delete #<procedure delete (_ _ #:optional _)>)
> ludo@ribbon /tmp [env]$ guile --version
> guile (GNU Guile) 2.9.8
>
> Here ‘delete’ is replaced by srfi-1, but the replaced bit is not
> propagated to module (x), even though (x) simply re-exports it.
>
> Should the #:re-export clause propagate the replace bit, or should
> it not? :-)
It is a good question :) Before, if you re-exported a #:replace
binding, it wasn't possible to have it be exported without the "replace"
bit set. After the change it is possible to do either, and the default
changes to not replacing. From NEWS:
Note to make this change, we had to change the way replacement flags
are stored, to being associated with modules instead of individual
variable objects. This means that users who #:re-export an imported
binding that was already marked as #:replace by another module will
now see warnings, as they need to use #:re-export-and-replace instead.
The 3.0 behavior differs from 2.2 in this regard, although it's just
warnings and not run-time behavior. I am sympathetic to the concern
that it can be difficult to make a system that warns/doesn't warn in the
same way on 2.2 vs 3.0 but I think the change is the right thing, as the
new behavior is more expressive. Because it's a user-visible change it
is in NEWS. LMK if you think we need a change here!
Andy
next prev parent reply other threads:[~2020-01-05 10:03 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-03 18:30 Re-exporting a replaced binding Ludovic Courtès
2020-01-04 15:57 ` Taylan Kammer
2020-01-05 10:03 ` Andy Wingo [this message]
2020-01-06 9:54 ` 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=87woa6z0d3.fsf@pobox.com \
--to=wingo@pobox.com \
--cc=guile-devel@gnu.org \
--cc=ludo@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).