Re: Trouble with `export'.

[Dirk Herrmann]

On 14 Jun 2001, Marius Vollmer wrote:

> The definition of (lookup-for-import MODULE SYMBOL WRITABLE? FORCE?) is
> 
>     - if FORCE? is true
> 
>       - return (lookup MODULE SYMBOL)
>         (but watching out for endless recursion and signalling
>          an error in that case.)
> 
>     - else
> 
>       - if SYMBOL is in both EXPORTED and RE-EXPORTED
> 
>         - signal a "identifier both exported and re-exported" error.
> 
>       - else if SYMBOL is in EXPORTED
> 
>         - if LOCAL contains a binding for SYMBOL:
> 
>           - return it
> 
>         - else
> 
>           - signal a "exporting undefined identifier" error.
> 
>       - else

Probably this should be 'else if SYMBOL is in RE-EXPORTED' ?

> 
>         - return what (lookup MODULE SYMBOL) returns but
>           only if it doesn't correspond to a binding from LOCAL.
>           Return #f in that case.  Also watch out for endless
>           recursion, possibly signalling an error.

OK, I think I understand your approach, although I am not sure about the
FORCE? import parameter.  And, another issue, it is more general to also
have the export list defined as pairs of (INTERNAL-NAME . EXTERNAL-NAME),
but that does not have any influence on the basic concept.

> All conflicts would be reported at lookup time, not when they are
> effectively introduced.

I see two points about this idea that I don't like:

* The need to check for conflicts at lookup time is more time consuming
  than to do this check at definition time.  While I can not really prove
  this statement, I base it on the assumption that you typically read a
  definition more often than you write it.  But, this is a performance
  issue which does not matter too much.

* Postponing the reporting of a conflict to a later time may leave a
  system in a buggy state.  Potentially, you never run over the conflict
  and ship your code, but some user will eventually detect it.  Or, you
  start a long running application and immediately before your results are
  printed the computation stops because a conflict is detected late.  This
  approach appears to me as if you would say "don't report division by
  zero errors immediately, but instead wait to the point when someone
  tries to use the result of the division - maybe it is never used".  IMO,
  the earlier a problem is detected, the better.  There are reasons for
  compile time type checking :-)

It seems to me that your main motivation is to keep the system comfortably
usable when working interactively.  Is that right?  Or do you think that
my point (i. e. not to define any precedence rules, but report any
conflict as an error immediately at import or definition time) has
principle flaws or that it is theoretically inferior to the less
restrictive approach?

If I am right that the main counterargument against the more restrictive
approach is, that you assume a noticeable loss of convenience, we should
probably think about whether this is really the case.  I believe that it
should be possible to provide convenient ways to fix 'broken' imports and
definitions interactively.

Best regards,
Dirk Herrmann