Re: r6rs libraries, round two

[Julian Graham]

Hi Guilers,

With the 1.9 series launched, I wanted to start thinking about R6RS
libraries again, since it would be awesome to have some semblance of
an implementation ready by October.


> I think such issues should lead us to have a `:version' option that does
> just what's needed for R6RS, and does not try to do anything smart
> (which could seem to be non-deterministic).  We could even go as far as
> discouraging its use in the manual.

Alright -- so, to summarize what (I think) has been decided:

1. Having more than one version of a module loaded at a time in a
single Guile process / VM is not going to be supported.

2. Mixing load calls that specify version with load calls that do not
should produce deterministic behavior independent of the set of
already-loaded modules.  (As described here: [1].)

R6RS says that the mechanism by which implementations match
version-less library references is implementation-dependent, but, in
order to avoid breaking rule number two, I think there's really only
one way to do it:

The expander has to recursively examine all of the imports, starting
with the top-level program, and keep track of the version specifiers
it finds.  In order for a program to be consistent with regard to
version, all of the version specifiers for a particular library name
must be prefixes of the most fully-specified version of that library.
If this is true, then once the most fully-specified version is
resolved, wildcard version specifiers can be resolved to that version.

Unfortunately, depending on the order in which imports are processed,
this mechanism might need to examine the headers of several versions
of a particular library.  So it's the most correct, but it may be
non-optimal.

A lazier but potentially less load-thrashy alternative would be to
have wildcard versions match the latest available version of a library
OR an already-loaded version of that library if present.

What do people think?


Regards,
Julian

[1] - http://www.mail-archive.com/address@hidden/msg03648.html