when to #:replace

when to #:replace

[Andy Wingo]

Hello,

As you probably know, Guile is fairly flexible when dealing with
duplicate bindings -- one can warn, error, choose the last one, first
one, etc.

But currently there are lots of warnings, way too many. For example just
using srfi-69 gives you a warning:

  WARNING: (guile-user): imported module (srfi srfi-69) overrides core binding `make-hash-table'

So I think there is confusion among both users and developers of Guile.
I thought a little about the problem and here's a kind of FAQ regarding
duplicate bindings:

  Q: I have a module that overrides a core binding (like
  make-hash-table). Should I #:export that binding or #:replace it?

  A: #:replace. Presumably the user knows what she is doing when she
  uses your module. If she really cares she can change the duplicate
  bindings resolution mechanism to disallow such imports.


  Q: How do I suppress duplicate bindings warnings?

  A: Fix your module so that you rename one of the bindings on import.


  Q: How do I suppress a "overrides core binding" warning when importing
  a module?

  A: Fix that module so that it uses #:replace for that binding instead
  of #:export.


Now, off to fix R6RS modules in this regard...

Andy
-- 
http://wingolog.org/

Re: when to #:replace

[Ludovic Courtès]

Hi!

Andy Wingo <wingo@pobox.com> writes:

>   Q: I have a module that overrides a core binding (like
>   make-hash-table). Should I #:export that binding or #:replace it?
>
>   A: #:replace. Presumably the user knows what she is doing when she
>   uses your module. If she really cares she can change the duplicate
>   bindings resolution mechanism to disallow such imports.

+1

But...

The manual currently says otherwise (info "(guile) Creating Guile
Modules"):

  `#:replace LIST'
        Export all identifiers in LIST (a list of symbols or pairs of
        symbols) and mark them as "replacing bindings".

        [...]

        This is useful for modules that export bindings that have the
        same name as core bindings.  `#:replace', in a sense, lets
        Guile know that the module _purposefully_ replaces a core
        binding.  It is important to note, however, that this binding
        replacement is confined to the name space of the module user.
        In other words, the value of the core binding in question
        remains unchanged for other modules.

        For instance, SRFI-39 exports a binding named
        `current-input-port' (*note SRFI-39::) that is a function
        which is upwardly compatible with the core
        `current-input-port' function.  Therefore, SRFI-39 exports
        its version with `#:replace'.

        SRFI-19, on the other hand, exports its own version of
        `current-time' (*note SRFI-19 Time::) which is not compatible
        with the core `current-time' function (*note Time::).
        Therefore, SRFI-19 does not use `#:replace'.

According to your rationale, SRFI-19 would #:replace ‘current-time’.

(See also http://www.mail-archive.com/guile-devel@gnu.org/msg00479.html
and http://www.mail-archive.com/guile-devel@gnu.org/msg00469.html .)

Thanks,
Ludo’.

Re: when to #:replace

[Andy Wingo]

On Sun 20 Jun 2010 23:29, ludo@gnu.org (Ludovic Courtès) writes:

> Hi!
>
> Andy Wingo <wingo@pobox.com> writes:
>
>>   A: #:replace. Presumably the user knows what she is doing when she
>>   uses your module. If she really cares she can change the duplicate
>>   bindings resolution mechanism to disallow such imports.
>
> +1

I'm glad you agree :)

> But...
[...]
>         SRFI-19, on the other hand, exports its own version of
>         `current-time' (*note SRFI-19 Time::) which is not compatible
>         with the core `current-time' function (*note Time::).
>         Therefore, SRFI-19 does not use `#:replace'.

But, srfi-1 uses #:replace for `list-index'. Though perhaps that isn't a
good example, as I've been bitten by it many times...

> According to your rationale, SRFI-19 would #:replace ‘current-time’.

Yes I think it should, and likewise with SRFI-69.

Andy
-- 
http://wingolog.org/

Re: when to #:replace

[Ludovic Courtès]

Merry Solstice!

Andy Wingo <wingo@pobox.com> writes:

> On Sun 20 Jun 2010 23:29, ludo@gnu.org (Ludovic Courtès) writes:
>
>> Hi!
>>
>> Andy Wingo <wingo@pobox.com> writes:
>>
>>>   A: #:replace. Presumably the user knows what she is doing when she
>>>   uses your module. If she really cares she can change the duplicate
>>>   bindings resolution mechanism to disallow such imports.
>>
>> +1
>
> I'm glad you agree :)

What I meant is that “we” should make sure the manual and various modules
are (mostly) consistent with this new policy, and document said policy
in the manual.

What d’you think?

Ludo’.

Re: when to #:replace

[Andy Wingo]

On Mon 21 Jun 2010 23:54, ludo@gnu.org (Ludovic Courtès) writes:

> Merry Solstice!
>
> Andy Wingo <wingo@pobox.com> writes:
>
>> On Sun 20 Jun 2010 23:29, ludo@gnu.org (Ludovic Courtès) writes:
>>
>>> Hi!
>>>
>>> Andy Wingo <wingo@pobox.com> writes:
>>>
>>>>   A: #:replace. Presumably the user knows what she is doing when she
>>>>   uses your module. If she really cares she can change the duplicate
>>>>   bindings resolution mechanism to disallow such imports.
>>>
>>> +1
>>
>> I'm glad you agree :)
>
> What I meant is that “we” should make sure the manual and various modules
> are (mostly) consistent with this new policy, and document said policy
> in the manual.
>
> What d’you think?

I agree :)

A
-- 
http://wingolog.org/

Re: when to #:replace

[Andy Wingo]

On Mon 21 Jun 2010 23:54, ludo@gnu.org (Ludovic Courtès) writes:

> Andy Wingo <wingo@pobox.com> writes:
>
>> On Sun 20 Jun 2010 23:29, ludo@gnu.org (Ludovic Courtès) writes:
>>
>>> Hi!
>>>
>>> Andy Wingo <wingo@pobox.com> writes:
>>>
>>>>   A: #:replace. Presumably the user knows what she is doing when she
>>>>   uses your module. If she really cares she can change the duplicate
>>>>   bindings resolution mechanism to disallow such imports.
>>>
>>> +1
>>
>> I'm glad you agree :)
>
> What I meant is that “we” should make sure the manual and various modules
> are (mostly) consistent with this new policy, and document said policy
> in the manual.
>
> What d’you think?

We should, yes :P  I took care of the docs, but help regarding modules
is much appreciated.

Andy
-- 
http://wingolog.org/