My current proposal on modules has an import form as a fixed part of the module form: it appears at the top, just after the export form and before the body. There is also import as a syntax keyword, used only at the top level. People have rightly argued that this is asymmetric and inflexible (though it is a bit more flexible than R6RS, which allows imports only at the top of top-level programs).
On the other hand, it is discoverable: one can tell, simply by reading in a file containing one or more modules, what other modules are required. There is a trade-off between flexibility and discoverability that makes The Right Thing hard to discern, and this time the problem cannot be swept under the rug, for the Steering Committee has insisted that small Scheme have modules. Here are some possible standpoints in the discoverability/flexibility tradeoff: 0) Imports only at the top of a module or the beginning of the top level. R6RS, but probably impossible for REPL-based semantics. 1) Imports only at the top of a module, but anywhere in the top level. My current conservative proposal. 2) Imports anywhere in a module or at the top level, but not embedded inside other forms, with the usual exception for begin. 3) Imports or macros that expand into them only at the top of a module, but anywhere in the top level (but not embedded). 4) Imports or macros that expand into them anywhere, but not embedded. 5) Imports or macros that expand into them anywhere, including embedded in other forms. 3CE, 4CE, 5CE) Only cond-expand macros are allowed to expand into imports, not arbitrary user-written macros. Comments? Other ideas? -- "Well, I'm back." --Sam John Cowan <[email protected]> _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
