This doesn't seem to help with the problem facing planet, namely how to tell if it is safe to instantiate a module twice or not. Planet can already instantiate both modules fine -- it just need to know it is safe to do so.
In your A/Z example, the question is if A and Z communicate B version 1 values to B version 2 or not (well, planet actually want to know if B version 1 can cope with B version 2 values coming back to it or not, roughly). Robby On Thu, Apr 7, 2011 at 2:02 PM, Matthias Felleisen <matth...@ccs.neu.edu> wrote: > > Lib A can link to an instantiation of Lib B version 1 > and > Lib Z can link to an instantiation of Lib B version 2 > > > > On Apr 7, 2011, at 3:01 PM, Robby Findler wrote: > >> How? >> >> Robby >> >> On Thu, Apr 7, 2011 at 12:47 PM, Matthias Felleisen >> <matth...@ccs.neu.edu> wrote: >>> >>> Units would solve this problem. >>> >>> >>> On Apr 7, 2011, at 7:32 AM, Robby Findler wrote: >>> >>>> On Wed, Apr 6, 2011 at 2:10 PM, Mark Engelberg <mark.engelb...@gmail.com> >>>> wrote: >>>>> The following two lines trigger an error: >>>>> >>>>> (require (planet dherman/memoize:3:1)) >>>>> (require (planet soegaard/math:1:4/math)) >>>>> >>>>> The error says something along the lines that the soegaard package >>>>> requires an older version of the memoize library, and the two can't >>>>> coexist. >>>>> >>>>> Shouldn't modules protect me from this? Shouldn't it be possible for >>>>> the math library to use its own required version of the memoize >>>>> library, without it screwing up my ability to require the latest >>>>> version of the memoize library? >>>> >>>> In the fully general case, this is not possible: you need to >>>> instantiate two copies of the same library and if that library has >>>> some external state (say a database connection) or even internal state >>>> that somehow goes from one version of the library to the other version >>>> via the other packages (imagine that there was a generative >>>> define-struct in there somewhere and values somehow make their way >>>> from one version's maker to another version's selector), then strange >>>> things start happening and the library breaks, through no real fault >>>> of its own. >>>> >>>> In the world of Racket modules, you never have two instantiations of a >>>> particular module at once -- they always share the same state (unless >>>> you monkey around at lower level using the introspection facilities) >>>> so when planet is asked to load two different versions into a single >>>> program, it decides to be conservative and signal an error, rather >>>> than violate this. >>>> >>>> That said, there are two things to note: >>>> >>>> - Planet has a kind of escape hatch where a library can declare that >>>> it is fine with being instantiated multiple times. See section 6.2.3 >>>> of the planet docs. >>>> >>>> - Planet was probably too conservative on this front and probably in >>>> Planet 2.0 the story will be different (and better). >>>> >>>> Robby >>>> >>>> _________________________________________________ >>>> For list-related administrative tasks: >>>> http://lists.racket-lang.org/listinfo/users >>> >>> > > _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/users
