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.  Technically this is outside the scope of the
language, so we *could* leave it to SRFI's or something - but as a
practical matter, a statement that some library is needed is flatly
useless if there is no standard way for the build environment to take
that statement and find the code associated with that library.

In the C world, there is the idea of an "include directory" for
<headers of> library code, and part of configuring a build environment
is telling it where the include directory/ies is/are (such as by
setting an environment variable or a registry value or a line in a
configuration file).  In fact, in most build environments there is
more than one such directory, and there's a configurable order in
which they are searched to resolve a named resource.

I'm not going to put a stick in the ground and ask for this system to
be copied verbatim with its assumptions about files and file/module
mappings, but let's be at least that useful.

There ought to be a repository for scheme library code on the system
somewhere (database, network resource, directory, whatever) that we
can direct any scheme environment to use, and scheme environments must
be scrupulous about not modifying that code nor requiring it to be
modified in any way that might interfere with the operation of other
scheme environments.  In other words, if we have a useful standard
here, then the same set of libraries ought to be available in my guile
and in my chicken and in my gambit environments, and with different
configuration, another user on the same system could point all three
to a different common set of libraries.  In order for library sharing
to be meaningful, the scheme implementations must not presume that
they have the right to modify these libraries or require
implementation-specific forms in them, because then other
implementations which are also using them will break.

I must say that I greatly prefer files and directories to databases or
network-based repositories for my own use, because that means there is
less infrastructure that must be working properly for the scheme
environments to work. And in principle, the best programming system is
the one that can be used with little or no infrastructure, because
it's what you use to *build* infrastructure.

Also, the tools available on most systems exclusive of the scheme
implementation itself are already capable of working properly with
files; The command line knows how to glob filenames, and ls and grep
and diff and cat and append are my friends, for example; analogous
utilities for the inspection, comparison, modification, and location
of database or network code outside the scheme systems are as yet far
less simple or useful.

				Bear