Many people contributed to the May 1994 discussion of modules and integration through the Usenet group comp.lang.scheme and subsequent e-mail (which form the basis for this idea). Tommy Thorn sparked my interest suggesting ways to reconcile "closing the world" with an interpreted dynamic top-level environment.
Matthias Blume pointed out the desirability of unnamed modules, showed that the interpreted vs. compiled issue was also true of changes in the order of files loaded, and elucidated the thorny area of macro exports. He also wrote convincingly of the usefulness of loading more than one version of a module. The modules outlined here allow this.
Paul Stodghill pointed out that first class environments can ameliorate
some of the problems I had with no-reserved-identifiers. Mikael
Pettersson suggested the analogy between identifier scope being static
and the load environment. Michael Blair improved my
understanding of what a compiler can and can't know about identifier and
macro scopes (and integration) without declarations.
Tom Lord, Marc Singer, and Miles Bader designed and implemented a local environment module system for GUILE. Marc Singer, in an insightful aside, opined that modules are just scoping constructs, after all.
Guillermo J. Rozas' created the very useful scheme-report-environment as part of his 1992 EVAL proposal for Scheme.
Per Bothner found connections with other implementation's module systems and helped refine the current proposal.
The module system for GUILE is more powerful than the one presented here. It is capable of dynamically creating and extending binding contours. While reading through some old messages on this subject, I realized that loading modules into a clean IEEE/R4RS-Scheme environment simultaneously solved the "closing the world", no-reserved-identifiers, and interpreted vs. compiled fealty requirements.
Go to the first, previous, next, last section, table of contents.