Re: r6rs libraries, round two

[Neil Jerram]

Julian Graham <address@hidden> writes:

> 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

Sounds good.

> * 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.

Given that your objective is to get R6RS library support in, I'd say
just stick to the R6RS format for now.  It sounds like it will be
fairly easy to extend this in future, if we want to.

>  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.

I can see the attraction of that, since I was experimenting two days
ago with adding the SHA-1 of the Git HEAD commit to Guile's micro
version - and it didn't work because of some restriction in
libguile/version.c (which I didn't investigate).

However, I still suggest just basic R6RS for now, because I'm sure we
could compatibly add more options later.

> 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?

As above, I suggest R6RS for now.

> * Should we establish some rules for what you get when you don't
> specify a version?

Yes!  The latest available?

>  Given what we've decided about loading multiple
> versions of a library (i.e., you can't)

I didn't follow why we decided that, but it feels wrong to me.  (It
seems to me that Guile should be able to handle loading ((foo) v1) and
((foo) v2) simultaneously as easily as it could handle loading
((foo-v1)) and ((foo-v2)) simultaneously.) I guess I should look up
the previous thread, please let me know if you have a convenient
reference.

> 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.

Agree, and agree that this feels wrong.

Regards,
        Neil