Re: Re-exporting a replaced binding

[Andy Wingo]

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