r6rs libraries, round two

[Julian Graham]

Hi Guilers,

I'd like to take another stab at getting R6RS library support in, this
time by extending the capabilities of the module system.  Here's what
I've got in mind to start with:

1. Add an optional `version' field to the module record type

* What's a good format here?  We could mirror the requirements of R6RS
here (i.e., (v1 v2 ...) where vx is a whole number) or be more
flexible.  For example, Apache Maven (I've got Java on the brain from
being at work) lets you specify the version of your project however
you want, but if you follow the convention its docs set out, it can do
things choose the "latest" version or match a version within a range.
We could do likewise.


2. Add support for optional version arguments to `use-modules',
`resolve-module', etc.

* Again, do we want to adhere strictly to R6RS-format version
references here or extend their syntax?

* Should we establish some rules for what you get when you don't
specify a version?  Given what we've decided about loading multiple
versions of a library (i.e., you can't) and the existing behavior of
the module-loading functions (you get an already-loaded module if
one's available), conflicts seem possible:

E.g., if not specifying a version equates to getting the "first
module" in the search path matching the name, then subsequent calls to
those functions that *do* specify a version reference may succeed or
fail based on the result of a prior call.


Regards,
Julian