Re: [PATCH] SRFI-34, SRFI-60 and core bindings

[Neil Jerram]

address@hidden (Ludovic Courtès) writes:

> Marius Vollmer <address@hidden> writes:
>
>> Often, the user of a module also knows that everything is alright and
>> wants to surpress the warning.  (That's where you come in,
>> Ludovic. :-) The user can only do that by giving parameters to
>> use-modules or its own define-module.  He should not go and add a
>> #:replace to the exporting module.  The only ways to do avoid the
>> duplicate warning for a module user currently are to rename the
>> bindings on import, or to use an explicit #:duplicates handler.
>> (Right?  Anything else?)
>
> I find this use of duplicate binding policies quite circumvoluted and
> unclean for that matter.

I agree with Ludovic.  What we have now seems seriously screwy, and
I'm sorry I didn't pay attention when this was first discussed and
implemented.

(duplicate-handlers is a module??!!  And there was me thinking we
already had quite a good class system in Guile.)

It seems completely wrong for the defining module to be responsible
for guessing which of its bindings might have the same name as other
bindings in the wide world outside that module.

In particular, this gives the absurd situation where a module can be
100% correct one day, then we add a new function to core Guile, and
that same module now becomes incorrect.

I'm not saying that it's bad that users of the module suddenly get a
warning in this situation; rather that it's wrong that the only
(practical) way to fix the warning is to update the _module_'s code.
(IMO using duplicate-handlers is far too heavyweight to be practical.)

It strikes me as a much more reasonable proposition for the _using_
module to be responsible for the bindings that it imports, and the
fact that we already have #:select, #:hide and #:renamer is in line
with this.  So it seems obvious that #:replace should really be
another option for use-modules and #:use-module, _not_ for
define-module.

Am I missing something?  I can't see any good arguments for the
current interface.

Regards,
        Neil