guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Marius Vollmer
Subject: Re: [comp.lang.lisp] Re: accessor name clashes when using packages
Date: 29 Aug 2001 22:00:07 +0200
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.0.102

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.

What srfi-1 should probably do is to explicitely overwrite the
definitions in `core' when it gets loaded, or make the extended
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'.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]