Hi Julian!
On Wed 22 Apr 2009 20:32, Julian Graham <jool...@gmail.com> writes:
> I have to confess, I'm totally at a loss as to how we're going to make
> versioning work with the autoload system.
>
> In particular, I see some difficulty in terms of determining whether
> to fully load and evaluate a module form during search. My
> understanding is that, in general terms, the existing system does the
> following:
>
> 1. Checks the set of registered modules
> 2. Locates a candidate module based on filename and loads it
> 3. Re-checks the set of registered modules
This is the process for the modules that exist currently. Note that no
module that currently exists has a version; so the lookup procedure for
versioned modules can be different than what we currently have.
For example, we can load a file, knowing with certainty that it should
define a module of the given name and version.
Not sure where I'm going with this ;)
But given that the non-normative Appendix F states:
Names for libraries may include a version. An import spec may
designate a set of acceptable versions that may be imported.
Conversely, only one version of each library should be part of a
program. This allows using the “name part” of a library name for
different purposes than the version.
In particular, if several different variants of a library exists
where it is feasible that they coexist in the same program, it is
recommended that different names be used for the variants. In
contrast, for compatible versions of a library where coexistence of
several versions is unnecessary and undesirable, it is recommended
that the same name and different versions be used. In particular, it
is recommended that new versions of libraries that are conservative
extensions of old ones differ only in the version, not in the name.
Correspondingly, it is recommended that import specs do not
constrain an import to a single version, but instead specify a wide
range of acceptable versions of a library.
Implementations that allow two libraries of the same name with
different versions to coexist in the same program should report when
processing a program that actually makes use of this extension.
Guile should probably only support one "live" version of a module. So
Guile's internal module namespace stays the same. Versions are only
important when loading files from disk. I propose that we do it like
this:
(foo bar) -> foo/bar.scm in the path, just as we have it now
(foo bar (n)) -> foo/barSEPn.scm, where SEP is some separator not
valid in identifiers.
Candidates for SEP? Unfortunately all the ones that can be bare in the
shell seem to be taken. Actually maybe `/' is a good candidate, or in
general the path separator. So it would be foo/bar/n.scm, where n would
be the version.
We then fix the path-searching functions in load.c to understand
versions -- some trickiness there but we can do it.
Cheers,
Andy
--
http://wingolog.org/
