Re: ModuLite: Scheme Module System proposal

[William D Clinger <will@ccs.neu.edu>]

Here are some technical comments on the ModuLite proposal.
Most of these comments are actually questions concerning
aspects that I don't understand.

One of the standard motivations for modules is to provide a
barrier between interface and implementation.  (Typically the
interface defines some notion of an abstract type, but it is
not absolutely necessary that this notion of type be enforced
by the module system.)  I didn't see this motivation listed
among the goals for either a module system or a library system.

In http://www-swiss.ai.mit.edu/~jaffer/modulite_4.html,
I don't understand why an environment is an ordered set of
bindings.  Ordinarily an environment is an unordered set of
bindings.  Why is ordering necessary here?

In http://www-swiss.ai.mit.edu/~jaffer/modulite_5.html,
I don't understand what definitions are being discussed in

    Make-module evaluates expression in a scheme report environment.
    Definitions occuring at the top level cause bindings to be created in the
    binding contour which the call to make-module creates and returns. 

If the expression is truly an expression, then it can't contain
any top-level definitions.  Does this have to do with the funny
treatment of LOAD, or is the expression allowed to be a body or
definition instead of an expression, or what?

I also don't understand

    Since identifiers bound to modules will not be visible while
    evaluating module source, the mechanism for translating module
    names to filenames should be part of the scheme report environment
    (although not specified in the report). 

In particular, http://www-swiss.ai.mit.edu/~jaffer/modulite_6.html
says

procedure: import-module modu 
       Modu should be a module as returned by module, make-module, or load-module.
       The import-module procedure adds the bindings from modu to the top level
       environment. If an identifier exported from modu already has a top level
       binding, that binding is occluded. 

Suppose, for example, that module M1 imports module M2, and that
both M1 and M2 contain a top-level definition of X.  Since M2 is
not visible when M1 is evaluated (according to text quoted above),
the evaluator must resolve references to X within M1 as references
to the X defined by M1.  But then that definition of X is to be
occluded by M2 (according to text quoted above).  Does that mean
the evaluator made a mistake when it resolved references to X
within M1 as references to the X defined by M1 instead of the X
defined by M2?  Or does it mean that references to X within M1
refer to the X defined by M1, but that references to X within
code that imports M1 will see the definition of X within M2
instead of the definition within M1?  A "yes" to either question
is problematic.

I too prefer explicit EXPORT to DEFINE-INTERNAL, but I think the
best solution is to be able to set the default either way, with
explicit overriding for particular identifiers.

Will