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
