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