On Wed 22 Apr 2009 22:22, Julian Graham <jool...@gmail.com> writes: > 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'.
I can imagine this, but I can't imagine it working. What if those modules dlopen different versions of a shared library? There's going to be breakage, one way or another. Better to error out, "Version 3.2 is already loaded, incompatible with >= 4.0", or something. I agree with Ludo that versions are a bit half-baked. We should do what it takes to support them, but my personal opinion is that we don't have to think more about the things that the editors forgot to think about -- i.e. concurrent versions of the same lib. The problem of upgrading a module's version within a running system seems to be isomorphic to reloading a module. Jao has some ideas about how to do that. > (foo bar baz (m n)) -> foo/bar/m/n/baz.scm Looks good to me! My two cents, Andy -- http://wingolog.org/
