Re: Trouble with `export'.

[Marius Vollmer]

Rob Browning <address@hidden> writes:

> > > In this situation, aren't you defining a binding that as far as the
> > > local module is concerned, already exists?
> > 
> > Yes, but it exists accidentally.  Moreover, I think the redefining of
> > existing bindings is ok...
> 
> Hmm.  It doesn't seem accidental to me.  You have to explicitly "use"
> another module which implies that you need to be aware of the symbols
> it exports.  I guess it depends on interpretation, 

Yes, "accidental" is the wrong word.  What I meant to imply was that
while you can control what definitions are done in your module, you
can not control what definitions are exported from a used module.  It
might work for one version a used module, but fails for the next since
a conflicting binding has been added to its interface.  When such a
conflict arises, I think local definitions in the using module should
take precedence, in a declarative way.  That is, they should shadow
the imported binding, independent of whether the local definition has
been done prior to importing or afterwards.  Imported bindings that
conflict with other imported bindings should signal an error.  In my
view.

Thus, I used "accidental" to mean that the binding was visible, but
the user is not aware of this.  Instead he goes on to define his own
binding.

> and I've probably not thought about this enough to understand all
> the ramifications,

Me neither...

> but I've tended to think of a (use-modules (bar)) as, in part, being
> effectively equivalent to (define foo ...) for every exported symbol
> in module bar.  Under that interpretation, a subsequent (define foo
> ...) in the module would be an error.

Hmm, I'd still want to be able to start a repl in the module and
redefine the existing functions, say.

> > The behavior of `export' and `re-export' will be this:
> 
> I can't think of any real problems with this proposal, but even here,
> I still tend to think that if you say:
> 
>   (use-modules (ice-9 script))
>   (define use-emacs-interface #t)
> 
> You should get an error.  It ought to be:
> 
>   (use-modules (ice-9 script))
>   (set! use-emacs-interface #t)

Hmm, I think both should be legal, but would be two very different
things.  If you want to modify the value of the use-emacs-interface
variable in the (ice-9 script) module, you would need to use the
latter.

The former will define a new variable with the name
use-emacs-interface in the local module, shadowing the one from (ice-9
script).  I'd say that this is a legal thing to do as well.  You might
not be aware that (ice-9 script) define use-emacs-interface, and you
don't care since you don't use it.  The conflict that arises can be
resolved consistently by saying that local definitions take precedence
over imported ones.

Warning: this post is full of sloppy terminology.