guile-devel
[Top][All Lists]
Advanced

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

Re: Trouble with `export'.


From: Marius Vollmer
Subject: Re: Trouble with `export'.
Date: 04 Jun 2001 17:48:52 +0200
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.0.102

Rob Browning <address@hidden> writes:

> Marius Vollmer <address@hidden> writes:
> 
> > 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.
> 
> Couldn't define check for this and issue a warning?

Yes, it could, but it would hurt performance unduly, I'm afraid.
Moreover, there is no good place for this check to be put, I think.
One place would be in scm_sym2var, but that is quite a low-level place
that doesn't know about public interfaces and stuff.  I don't want to
put a kluge in there if we can avoid it.

> Presuming I understand the situation, it seems like it could be
> considered an error condition.

Hmm, not really, I'd say.  What `define' could do is to check whether
the right variable is in the public interface and correct it if its
the wrong one.  This feels unclean to me.

> 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, unless I hear otherwise, I think I'm going with the `export' and
`re-export' distinction.  This distinction might not be necessary in a
well-designed module system, but even there, it might carry
information that allows for more intelligent error checks.

The behavior of `export' and `re-export' will be this:

    `(export name)' will make sure that there is a local variable
    bound to `name' in the current module and will put that variable
    into the public interface, bound to `name'.  If it has to create a
    new variable, it will start out as uninitialized so that accesses
    to it will get an error.

    `(re-export name)' will find the variable corresponding to `name'
    in the uses list of the current-module and put it into the public
    interface.  It there is no such variable, it will signal an error.

The cost will be that all existing re-exports need to be found and
rewritten.  I think that is tolerable.

This is not completely declarative, and we might want this to work:

    (re-export baz)          ;; Re-export `baz` from ...
    (use-modules (foo bar))  ;; ... module (foo bar)

but I think we can live with this limitation.



reply via email to

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