Re: Trouble with `export'.

[Marius Vollmer]

Dirk Herrmann <address@hidden> writes:

> I don't remember in which context I read about the idea, it may be that it
> comes from the units modules system.  The key point is, that any module
> provides one or more signatures, which are basically lists of exported
> identifiers.  These lists can be used when importing a module as a
> convenient way of stating the list of identifiers to import.

I don't see how this is significantly different from what we have now.
In my understanding, signatures are a way for a module to specify
multiple lists of exported definitions, while we can only specify one
such list per module.  A signature is not more fixed than the set of
exported bindings in our current system (i.e. "signature" is just a
short name for "set of exported bindings", and our modules can only
have one signature).

A signature needs to be able to change over time as well.  With this,
I'm not so much referring to changes during the lifetime of one
process, but more to changes during development of a module, from one
version to the next.

In a (potentially) interactive system like Guile, changes during the
life time of one process are also important, see below.

> [...]
>
> If, in addition, it is an error to do (define a <something>) if a has been
> imported from some module before, we should have everything that is needed
> to detect all kinds of conflicts.

This is a different issue.  It's about what would be considered a
"simple and obvious" rule.  I lean towards allowing local definitions
to shadow imported ones, you tend to lean the other way.  If there is
a significant controversy about this, we might want to provide both
options.  (But which one to make the default??? ;-)

> (It doesn't need to be an error, a warning message could also be
> appropriate).  The only thing that has then to be done is to also
> provide some comfortable means to interactively fix such conflicts.

Yes, that's probably best solved with a enhanced condition/restart
system that applies to all kind of errors.

> I'd prefer such a more restrictive solution over the idea to have local
> definitions take precedence silently.  For example, if you have imported a
> binding, it may already be memoized at a couple of places.  If you
> overwrite the binding with a local definition, what do you want to happen?

The memoization should be redone so that it refers to the correct
binding.  This is what the observers are for in the `environment' data
type.

> As simple and obvious the "local definitions take precedence over
> imported ones" rule may be, I assume that there are a couple of
> problems associated with it, maybe also with any other 'implicit'
> rules.  IMO, it is better to have the user decide in every single
> case.  The user may then also fix the imports and exports to have a
> clean set of bindings the next time the code is executed.

Yes, I think that's a valid position to take, although I'm wouldn't
want it for the code that I write.