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

[Gary Houston]

> From: Marius Vollmer <address@hidden>
> Date: 29 Aug 2001 22:00:07 +0200
> 
> Gary Houston <address@hidden> writes:
> 
> > > From: Marius Vollmer <address@hidden>
> > > Date: 25 Aug 2001 23:43:50 +0200
> > > 
> > > Rob Browning <address@hidden> writes:
> > > 
> > > > I think we should arrange for the evaluator to make noise whenever
> > > > one imported binding is implicitly clobbering another.
> > > 
> > > Yes, definitely.  the simplest thing would be to change
> > > scm_module_variable and module-variable to check for duplicates and
> > > issue an error when they find one.
> > > 
> > > Hmm, I guess it would be good to do this right away even if we are
> > > going to do slightly differently in the future.  Let's see how many
> > > conflicts we have already...
> > > 
> > > Objections?
> > 
> > Wouldn't it break the srfi-1 module, among others?  e.g., if you use
> > srfi-1 then iota, map etc., are imported from both (guile) and
> > (srfi-1).
> 
> Yes, but I would regard that as `bugs' in the srfi-1 code (not that
> anyone is to blame for them).  Currently, it's mostly by accident (or
> low-level kludge) that you are picking up the definitions from srfi-1,
> and that this is Right Thing.  This should be more explicit.
> 
> We should probably first fix (guile-core).  Currently it exports every
> definition, which is, errm, sub-optimal.

Perhaps the right thing for (guile) is to remove it.  The contents
could be moved to as many well-defined modules as seem necessary.  Any
minor incompatibility this may cause can be easily worked around by
bumping up the major version number :-)

> 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?  That could be a bit dodgy.

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