Re: ModuLite: Scheme Module System proposal

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

Thank you for your clarifications.  Two minor comments:

    Order is the mechanism to resolve which binding occludes
    which when an identifier is bound in more than one contour.

If you define environments as (unordered) sets, and the
environment extension operator _[_:_] by

  e[x:v] = (e - { x:w | w is any value }) \union { x:v }

then environments don't need to be ordered.  This is a cleaner,
more abstract, and potentially more efficient view of
environments.  The problem with using ordered environments
in the specification of a module system is that it misleads
implementors into thinking that they must maintain the ordering
in their representations of the environments.  In any reasonable
module system it will of course turn out that the ordering is
irrelevant, because for all variables only the first binding
is actually relevant, but this becomes a global property of
the module system instead of a local property of environments.

    When an EXPORT statement is present, the only default which makes
    sense is non-export.  When a DEFINE-INTERNAL statement is present
    and EXPORT is not, the only default which makes sense is export.
    When neither EXPORT nor DEFINE-INTERNAL statements are present,
    the only default which makes sense is export.

This sounds reasonable but it isn't true.  Consider a macro that
expands into a sequence of definitions, but doesn't know whether
it will be expanded in an export-by-default context or in a
don't-export-by-default context.  This macro might well specify
an explicit EXPORT or DONT-EXPORT (i.e. DEFINE-INTERNAL) for
each definition in the expanded code.  This macro might then be
used in a context where some of the other definitions are being
exported or not-exported by default.

Will