[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