Re: Trouble with `export'.

[Dirk Herrmann]

On 4 Jun 2001, Marius Vollmer wrote:

> Prior to that change, re-exporting imported bindings would not work
> exactly right.  This code
> 
>     (define-module (mod1))
>     (export name1)          ;; Create uninitialized var1 and put it 
>                             ;; into mod1 and the interface of mod1
>     (define name1 12)       ;; Store 12 in var1
> 
> 
>     (define-module (mod2))
>     (use-modules (mod1))    ;; Make var1 visible with the name name1
>     (export name1)          ;; create var2 and initialize it with the
>                             ;; value of var1.  Put var2 into mod2 and
>                             ;; its interface.
> 
>     (define-module (mod3))
>     (use-modules (mod2))    ;; Make var2 visible with the name name1
>     (set! name1 123)        ;; Store 123 into var2.  Wrong.
> 
> would create two variables.  This is not the right thing, since we
> want modifications to be consistent.
> 
> After the change, this would work right.  However, this code
> 
>     (define-module (mod1))
>     (export name1)          ;; Create uninitialized var1 and put it 
>                             ;; into mod1 and the interface of mod1
>     (define name1 12)       ;; Store 12 in var1
> 
> 
>     (define-module (mod2))
>     (use-modules (mod1))    ;; Make var1 visible with the name name1
>     (export name1)          ;; Put var1 into the public interface of mod2
>     (define name1 123)      ;; Create var2 with name name1 and store 12 in it.
> 
> 
>     (define-module (mod3))
>     (use-modules (mod2))    ;; Make var1 visible with the name name1
>     (display name1)         ;; Display 12.  Wrong.
> 
> will put the wrong variable into the public interface of mod2.  This
> happens since `export' can not know whether there will be a local
> definition for a name later on.

I am surprised about the way that define works according to your examples,
i. e. that an imported binding will be shadowed by a local one.  Instead,
it seems that define should behave like set! whenever a binding already
exists, independent of whether it is a local or an imported binding.  If
that is not desired, the import list should be fixed.

We can not solve all problems with respect to binding conflicts, but we
should decide about a policy, like for example that conflicts will result
in errors.  With the possibility to selectively import bindings, and in
addition to rename bindings when imported, plus the possibility to rename
bindings when exporting them there should be enough possiblilities to
avoid conflicts while still being flexible.

Best regards,
Dirk Herrmann