[Top][All Lists]

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

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

From: Andy Wingo
Subject: Re: Merging Guile-R6RS-Libs in `master'
Date: Wed, 22 Apr 2009 23:53:29 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.92 (gnu/linux)

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,


reply via email to

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