[pypy-dev] Why is there a separate ExecutionContext?
Rocco Moretti
roccomoretti at netscape.net
Tue Mar 18 04:49:14 CET 2003
Sorry for the weeks of radio silence, life has a way of taking up your time.
>> > Actually, in the interest of generality, I'd argue that
>> > ExecutionContexts
>> > should not contain a link to the object space - it should be
>> > a per frame value.
There seems to be confusion on what I mean, so let me see if I can clarify.
I hope we all agree that one of the powers of the ObjectSpace concept is
the possibility of using multiple ObjectSpaces in the same program. We
already have this implicitly with Python objects and C language objects.
We could have an ObjectSpace for Psyco-ized code, or allow legacy
ObjectSpaces - run 1.5.2 semantic objects in otherwise 2.5.3 codebase.
So in this use of multiple ObjectSpaces, I'm mostly thinking in terms of
libraries. You, personally, would likely stick to one ObjectSpace, but you
may need to call into a library that uses a 1.5.2 object space, or a
Prolog object space.
Thus arises the concept that a function in one object space would have to
call a function in another object space. But this meams that the Execution
Context is not in a stable object space. In the parent function it has one
object space, and when the library function is called, a function with a
different object space is pushed onto the frame stack.
Unless ...<thinking outloud> execution contexts can be nested. The calling
function is in one execution context, and that spawns a daughter execution
context in a different objectspace that handles the called function. The
concept change (at least for me) is from that of a monolithic execution
context that has global scope and static duration to more flexible
execution contexts that have a more fleeting existence.
In any case, the trick is interfacing between the different object spaces.
A Prolog list does not behave like a Python list, so what happens when you
try to concatanate them? This exchange of object spaces can happen in two
locations - argument/return value passing and global values. I'm not sure
how this should be handled. I'd advocate delaying the descision until we
have two or more substantial object spaces we want to interface.
But for initial musings, I'd probably caution against a mixed approach
where each object retains it's semantics when it traverses into a
different object space. It probably would get too confusing to track down
bugs and dependancies, and the possible interactions would increase
exponentially. (As well as defeting the purpouse of having seperate Object
Spaces).
I'd probably advocate for an interface based approach. As arguments are
passed into a different object space, there are conversion routines which
define how a particular object from one object space is converted into a
native object in the other object space. The same happens in the reverse
direction. If a cross-ObjectSpace global lookup occurs, the interpreter
catches it and does the appropriate conversion. If it is nonsensical or
impossible to convert the object, an exception is raised.
A problem that immediately comes to mind is what to do about mutable
objects which are passed to the function and then altered. How are they
passed back? (What if the parent object space doesn't have "mutable"
objects, but the called one does?)
I hope that clears things up,
-Rocco
__________________________________________________________________
Try AOL and get 1045 hours FREE for 45 days!
http://free.aol.com/tryaolfree/index.adp?375380
Get AOL Instant Messenger 5.1 for FREE! Download Now!
http://aim.aol.com/aimnew/Aim/register.adp?promos=380455
More information about the Pypy-dev
mailing list