On Fri 03 Jan 2020 19:30, Ludovic Courtès <l...@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
