Re: [comp.lang.lisp] Re: accessor name clashes when using packages

[Gary Houston]

> From: Marius Vollmer <address@hidden>
> Date: 06 Sep 2001 01:51:20 +0200
> 
> Gary Houston <address@hidden> writes:
> 
> > > What srfi-1 should probably do is to explicitely overwrite the
> > > definitions in `core' when it gets loaded, or make the extended
> > 
> > I'm not sure what you mean by this: is it that a module that needs
> > to redefine a core feature (i.e., anything available by default at
> > startup) would go and hack the new definition directly into the
> > conflicting module?
> 
> Yes.
> 
> > That could be a bit dodgy.
> 
> Yep, agreed.
> 
> > > semantics of srfi-1 _be_ the core definitions.  Let's just do the
> > > latter.  That is, `iota' in boot-9.scm is replaced with the code from
> > > srfi-1.scm and srfi-1.scm does not define `iota'.
> > 
> > Would it not be better to remove iota from boot-9.scm, given that it's
> > available in srfi-1?
> 
> That would be an incompatible change, as you say yourself.  Do we want
> that?

I don't think it's too bad, since the boot-9 version of iota (and the
other definitions with the same problem) could be deprecated in the
usual way.  This would delay the module system change, but that's more
fundamental and can't be handled using deprecation.

The problem of conflicting definitions doesn't seem to have a good
solution yet.  Some observations:

The problem would be much smaller if guile didn't have so many random
definitions in the root module.

It seems like the Right Thing to have an R5RS module with facilities
that haven't been extended by SRFIs or other modules.  There's no
guarantee that there won't be conflicting alternative definitions in
any case.

It seems like the Right Thing for the SRFI modules to export their own
extended versions of these facilities if that's what the SRFI specifies.

It should be easy to use the SRFI modules without needing to deal with
every conflicting definition explicitly.

The result of the use-modules or define-module should be well-defined,
not dependent on the order in which modules are included.

There are other conflicting definitions besides SRFI modules, e.g.,
format vs simple-format, and guile-scsh redefines things like file-open
to behave like scheme-48 versions.

When a module replaces a definition from a default module, this change
should only be visible within the scope that the module is used.


Based on these observations, it seems that neither the current behaviour
nor the proposed error-on-conflict change is ideal.

Are there any alternatives that could be considered?  E.g., would it
be practical to allow a module to specify that a particular definition
always overrides a definition some other module, unless stated otherwise
in the use-modules statement?   Since use-modules has the job of 
modifying the bindings in the current module, it should be possible for
it to remove a conflicting import without ambiguity.