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

[ludovic.courtes@laas.fr (Ludovic Courtès)]

Hi,

Neil Jerram <neil@ossau.uklinux.net> writes:

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

I disagree.  The set of core bindings is not supposed to be very large,
and it's not that hard to see whether you're overriding a core binding.
Given that, that doesn't seem too much of a burden for the defining
module to explicitly warn its users (via `#:replace') of its intention
to override a core binding.

> 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 don't think this is an issue, practically.  Theoretically, that should
_not_ be an issue because we should try to keep the set of core bindings
as small as possible IMO.

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

In a way, this is already what happens:

1. The defining module provides a /hint/ about purposefully overridden
   bindings, via a `#:replace' option to `define-module';

2. The using module is /free/ to take such hints into account; by
   default, it will do so, because it will be using the `replace'
   duplicate binding handling policy (see the recent additions to the
   manual in HEAD).

My conclusion is that the current interface is actually quite good.  It
just needs to be well documented.  :-)

Thanks, and best wishes!

Ludovic.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel