Re-exporting a replaced binding

Re-exporting a replaced binding

[Ludovic Courtès]

Hi again!

I’m not sure if this is an intended consequence of
cf08dbdc189f0005cab6f2ec7b23ed9d150ec43d, so I thought I’d share this
example of a practical effect:

--8<---------------cut here---------------start------------->8---
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
--8<---------------cut here---------------end--------------->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?  :-)

(In Guile < 3.x, #:re-export would propagate the replace bit since that
bit was associated with the variable itself.)

Ludo’.

Re: Re-exporting a replaced binding

[Taylan Kammer]

On 03.01.2020 19:30, Ludovic Courtès wrote:
> 
> Should the #:re-export clause propagate the replace bit, or should
> it not?  :-)

The 2.9.8 release notes say one should use #:re-export-and-replace for
this use-case.


Happy new year!

Taylan

Re: Re-exporting a replaced binding

[Andy Wingo]

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

Re: Re-exporting a replaced binding

[Ludovic Courtès]

Hi!

Andy Wingo <wingo@pobox.com> skribis:

> On Fri 03 Jan 2020 19:30, Ludovic Courtès <ludo@gnu.org> writes:

[...]

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

I agree that the new mechanism is more expressive, I guess I just hadn’t
realized how it affects re-exports of already-exported bindings.  It’s
easily addressed anyway.

Thank you!

Ludo’.