Thu Nov 4 12:26:43 EST 2004
> > I don't like very much the INCLUDE of CODE solution because it forces you
> > to right in FILENAME in your code. As I have said, I think that we should
> > avoid that.
> Ok, we fundamentally disagree on this one.
I agree with Manuel here. When filenames are placed in the module,
the module becomes dependent on the filesystem and where the modules
are placed and also the filename syntax of the operating system. This
goes against the principle of modularity. I would like people to
share modules without having to change the filenames in the module to
suit local filesystem structuring conventions or the structure of the
system in which they want to use this module.
This is why in Snowbird I said we should only allow symbolic names for
modules, and rely on some mechanism outside of the module to indicate
how these symbolic names get mapped to files (or URLs, or ...). There
are several possibilities:
1) A standard search algorithm, e.g. look in the current directory for
a file with the same filename as the module name plus a standard
extension (you could use symbolic links to implement a more complex
mapping) and if that file does not exist then look in SPAN.
2) The mapping is specified to the compiler in a configuration file
(either specified explicitly on the compiler's command line or, if
none is specified, then in a file in the same directory with a
standard name, such as "config.scm").
3) A file of code implicitly starts with an (include "config.scm"),
if config.scm exists. If we also have a module indirection
form like (module foo "/usr/share/scheme/foo.scm") which indicates
in which file the module foo resides, then the config.scm file could
contain a set of module indirection forms.
Note that these configuration files could be generated automatically
by a tool that implements a particular type of system structuring
convention (Manuel mentionned such a tool for Bigloo in Snowbird).
More information about the R6RS