[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Julian Graham
Subject: Re: Merging Guile-R6RS-Libs in `master'
Date: Wed, 22 Apr 2009 16:22:57 -0400

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]