[R6RS] modules

William D Clinger will
Fri Aug 20 08:45:30 EDT 2004


  * Should every r6rs program have the same kind of wrapper as is
    required for libraries?  (Matthew prefers so; I prefer not.)

I prefer not.  To require such a wrapper would create a perception
(and possibly a reality) of greater complexity in the simplest
programs.  Consider, for example, the effect of this wrapper on
the exercise that asks students to write a self-reproducing
program.

  * Should bindings established by run-time require shadow bindings
    that would otherwise be visible within transformers, and visa
    versa?  For example, if M exports x, does
      (let ([x 3]) (require only-for-syntax M) x)
    evaluate to 3 or to an out-of-context error?  (I prefer error;
    I'm not sure about Matthew.)

Error.

  * Related to the above, should module expressions and commands be
    evaluated once for each "level" of require/require for-syntax or
    just once the first time needed?  (I prefer once; I'm not sure
    about Matthew.)

I prefer to let this be implementation-dependent.  If we must
specify it, I'd prefer once.

  * How are modules identified?  Possibilities include by name and
    by normalized pathname.  (I prefer by name with the pathname being
    advisory---information about where to find the module if it isn't
    already loaded.  I believe that Matthew prefers by normalized
    pathname, which is what MzScheme currently does.)

I like Kent's preference: by name with the pathname being advisory.

  * Are module exports settable by the exporting module and/or importing
    module? (I prefer that modules be used to control scope, not mutation
    policy, so I would say that variables are settable.  one can always
    export accessors/setters for hidden exports to obtain finer control.)

I prefer that exported variables not be assignable by importing code.
One can always export setters.

  * Can more than one module appear in a file?  (If modules are identified
    by normalized pathname, it probably makes sense to have only one
    module per file; otherwise more than one may be reasonable.)

Yes, please.

  * Must one declare "implicit" exports, i.e., local identifiers,
    references to which may be contained in the expanded output of an
    exported macro?  (I prefer yes, since this improves security and
    gives the implementation a chance to treat the remaining variables
    more efficiently.)

Yes.

Will


More information about the R6RS mailing list