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

[Andy Wingo]

On Wed 22 Apr 2009 22:22, Julian Graham <address@hidden> 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/