Re: Trouble with `export'.

[Dirk Herrmann]

On 7 Jun 2001, Marius Vollmer wrote:

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

Except that a signature is explicit, while the set of imported bindings is
implicit.  As I said, I consider the 'import-all' paradigm broken.  Your
counterargument was basically the typing effort.  This typing effort is
eliminated with signatures.

Thus, the significant difference with signatures is that you can make use
of the restrictive paradigm that for every binding it has to be stated
from which module the binding comes, while still having a comfortable way
of importing large sets of bindings.

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

If with a new module version the signature changes, yes, you may run into
problems.  For example, module foo's old signature was (a b c) and the new
one is (a b c d).  If some module bar had defined its own binding for 'd',
this would cause an error with the restrictive solution.  So what?  The
conflict can easily be solved, for example by only importing (a b
c) again, by importing 'd' under a different local name, or by
choosing a different name for the locally defined 'd'.

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

This is nice for interactive usage.  However, for compilation, it is not
very good, since shadowing a binding will mean that during compilation you
can not rely on the rule that every identifier is bound to a single
location:  If 'x' is shadowed, the location of x before and after the
shadowing will change.  If the compiler has to be aware of such
situations, this inhibits the optimization potential.

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

I wonder, whether conflicts would occur very frequently.  If they occur
very frequently, I could understand your point:  If people would be
confronted with the need to react on conflict errors very often, then the
need to keep the interfaces up to date frequently would be tedious.  And,
if it is a frequent situation, people would also be aware of the
'shadowing rule', since it was some everyday's concern.

If conflicts occur seldom, I'd argue the other way around:  It is then not
much effort to update the imports and exports, and the awareness of
potentially shadowed bindings would also be much worse.

I think my personal attitude towards this issue comes from the fact that I
generally prefer to be informed about potential problems.  It is the same
with compiler warning messages:  I prefer to be warned once too often
about a potential problem than once too less.

Best regards,
Dirk Herrmann