This page is part of the web mail archives of SRFI 83 from before July 7th, 2015. The new archives for SRFI 83 contain all messages, not just those from before July 7th, 2015.
On 1/16/06, bear <bear@xxxxxxxxx> wrote: > > On Fri, 13 Jan 2006, Per Bothner wrote: > > > Finding modules. How does an implementation or a user resolve > > a module name to a module definition? > > I just wanted to quote this question, because answering it is VERY > IMPORTANT. There needs to be some standard way for a scheme to > resolve modules. Agreed, this is also a very important issue (though orthogonal to whether modules themselves use single or multi-sexp declarations). The question is how much needs to be said about this in the standard itself. At the one extreme you can wave your hands and say "the Scheme implementation can macro-expand the byte-stream, determine what modules are in it, and store the result in a registry." Because this is always possible, you don't actually need to specify anything in the standard. However by leaving things this open you effectively *require* implementations to maintain a registry database if they want to support all valid modules. At the other extreme, to avoid this and ensure maximum portability and convenience of sharing modules you want to specify the exact file names to be used, including nailing down the extension (currently mostly split between .scm and .ss). The vast majority of implementations do in fact translate module names directly to filesystem paths without any use of a registry. How much should be said of this? Something like: When making modules available via a URI or pathname, for ease of interoperability one should translate the module name in such-and-such a way to obtain the relative URI or pathname. Admittedly it sounds awkward. It's also entirely pending on the naming convention which is currently unspecified. On the other hand, it makes no claims about such things as load time or load paths, and even if traditional file names go out of style, URI's are likely to be around for a long, long time, so such a statement in the standard isn't locking us into some "outdated idea." As to whether or not multiple modules should be allowed in the same byte-stream, I don't see why not. The typical case is that of a main module and one or more small helper modules, not meant to be accessed directly from the outside. The name of main module would be the one used for URI resolution, and the helper modules would just get loaded at the same time. This in fact already works as-is in many implementations, including Kawa. -- Alex