[Top][All Lists]
[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.
Re: Trouble with `export'., Dirk Herrmann, 2001/06/05