On 1/16/06, bear <xxxxxx@sonic.net> 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