Re: Merging Guile-R6RS-Libs in `master'

[Julian Graham <joolean@gmail.com>]

Hi Andy,

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

Actually, I'd like to disagree here -- maybe I've been writing too
much Java, but isn't it possible that the VM would be running more
than one "program" (or maybe I misunderstand that term)?  Or let's say
that I absolutely need version 4 of library `foo', but that in the
transitive closure of my library dependencies, there's another library
(which I may prefer not to modify) that absolutely needs version 3 of
`foo'.


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

I like this, except it puts the constraint on module authors that
their source files need to be named n.scm.  Maybe that's not a big
deal (and it could be mitigated with some kind of "install"
procedure), but what if the mapping were:

(foo bar baz (m n)) -> foo/bar/m/n/baz.scm


Regards,
Julian