Re: Trouble with `export'.

[Marius Vollmer]

Dirk Herrmann <address@hidden> writes:

> On 7 Jun 2001, Marius Vollmer wrote:
> 
> > 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.

In what way is a signature explicit?  Looks like I don't understand
the concept of signatures.  What I have in mind is that we might say

    (use-modules ((foo bar) :signature frob))

to effect that the bindings belonging to the frob signature are
imported into the current module.  But _which_ bindings this are
exactly is defined elsewhere, alongside the (foo bar) module.

> As I said, I consider the 'import-all' paradigm broken.

I'd say that with signatures, you have the same `import-all'
semantics.  "Import all of the signature."

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

I don't see how you can have a explicit list of imported bindings
without writing down that explicit list.  Referring to shortcuts
defined elsewhere doesn't really work, since you don't know for sure
what they expand into.

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

Yes, it can be resolved, but I think your argument for signatures is
that conflicst wouldn't arise in the first place, since the list of
imported bindings was explicit to be begin with.

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

But you can't do that by using the signature, you would have to write
out the list in full.  Thus, you would have to go from a nice and
short summarized importing clause to a potentially long one, maybe
needing to go thru your whole file to find out what bindings you
actually use.

In contrast to that, if local bindings would silently shadow imported
ones, the bar module would simple continue to work, since it is
unaffected by the new binding appearing in the foo module.

> If the compiler has to be aware of such situations, this inhibits
> the optimization potential.

Yes, it would make cross-module optimizations harder.  But I'd say
that the compiler shouldn't by default make any cross-module
optimizations anyway, since making implementation details leak out
from a module runs counter to a modules primary purpose:
modularization.  Some cross-module optimizations are important and
feasible: we would certainly want the compiler to open-code
arithmetics on fixnums, for example.  But I would say that the
compiler needs to be specifically instructed for each such case.  It
shouldn't by default assume anything about functions from other
modules.  (And if it does make assumptions, the code should check at
load time whether these assumptions are still valid.)