Re: Trouble with `export'.

[Dirk Herrmann]

On 5 Jun 2001, Marius Vollmer wrote:

> Dirk Herrmann <address@hidden> writes:
> 
> > [...] It seems that the 'import all' paradigm itself is broken.
> 
> But it's soo convenient.  Imagine using (gtk gtk) for a largish GUI
> and having to state 200 or so gtk functions that you are using,
> although they all start with `gtk-'.  People would hate us for this
> I'm sure.
> 
> > You would never run into problems if you had to state explicitly
> > where each binding should come from.  Or, more exactly, you still
> > could run into conflicts, but all these conflicts should be
> > detectable and not happen silently.
> 
> I think this is the key property: conflicts should be detected and
> either resolved with simple and obvious rules or signalled as an
> error.  What is simple and obvious is of course open to
> interpretation, and modules might even select their own set of rules.
> I'd say that "local definitions take precedence over imported ones" is
> simple and obvious, but "for two imported definitions, the one that
> has been imported earlier takes precedence, where `earlier' means..."
> is not simple or obvious.  Well, I have committed the export/re-export
> distinction already and even made `export' backward compatible
> temporarily, spiting out a deprecation warning.

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.  For the gtk
example that means that you would not have to enter the list of
identifiers manually, but instead you could use a list that was provided
by the module developer.

This way, there is no possibility of adding a definition to an already
imported module and making this one implicitly visible.  It doesn't mean
that you couldn't add a definition to an already imported module:  You
still could do so, but to make it visible in the importing module you
would have to import the new binding explicitly.

For example:

Module foo provides foo-all which is (a b c).  To import everything from
foo, you could say something like (use-modules (foo) :import-signature
foo-all), which is an 'import-all', but with a fixed set of imported
identifiers.  This should also be sufficiently convenient, right?

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.  (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.

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?
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.

Best regards,
Dirk Herrmann