Extending the ObjectSpace Concept
I think it may be worthwhile to extend the concept of Object Spaces to the bytecode and sourcecode levels. (Provisional names: BytecodeSpace and SyntaxSpace.) Just as an ObjectSpace embokdies the abstract concept of the semantics of objects and their interactions, a Bytecode space embodies the concept of the bytecode and its effect on execution flow control. Likewise, a SyntaxSpace embodies the abstract concept of the textual program and its mapping onto bytecode and object definitons. Now, these spaces are distinct, but they are not independant. The SyntaxSpace needs to know which BytecodeSpace and ObjectSpace to use to output functions and objects, a BytecodeSpace needs to know what ObjectSpace to use to implement object interactions, and an ObjectSpace needs to have some idea about SyntaxSpaces and Bytecode spaces so that it can compile strings and execute functions. As I imagine it currently, the ObjectSpace will be the controlling space. A string or file is given to the ObjectSpace to execute. It passes the string to the SyntaxSpace, which then compiles it into a number of ObjectSpace objects, including module, function and code objects. The object space then executes those functions by passing them to the appropriate BytecodeSpace. In the process of execution, the BytecodeSpace then calls back to the ObjectSpace to implement the object semantics. Note that there is a distinction between BytecodeSpaces and the an ExecutionContext, in that each BytecodeSpace would have singleton semantics, but there can be multiple different ExecutionContexts. (Perhaps it could be as simple as a class/instance distinction.) Perhaps the Bytecode/Syntax Spaces don't need to be actual entities, but could stay as abstract concepts. If accepted, one change that should be made is to shift the function call semantics in the object space to have an explicit execution context as a parameter, so that it is clear that the ObjectSpace is controling execution. Which sort of leads me to the reason I got on this train of thought. Over the past couple of weeks I've been trying to fix the remaining bugs in the trivial object space. Some of them seem to stem (at least in part) to the lack of a separate sys/builtins module for the application level code. (As was mentioned earlier by mwh). I've attempted to fix it by special casing the builtin __import__(). However, in order to do so, __import__() needs to be able to call out to interpreter level python functions. With the current TrivialObjectSpace, that's impossible as all python functions are run through the pypy interpreter. As I see it, there are two simultaneous execution "threads" running through the interpreter. The host interpreted "interperter level" functions, and the pypy interpreted "application level" functions. The host interperter takes care of the first, so I'll deal with the second. You can split the application level functions into three categories: Application Space Functions: Python functions which should be run under the pypy interpreter. (i.e. User code) Interpreter Level Python Functions: Functions written in Python which need to be run on the host interpreter. These are functions which are called from and return to user code. (Like a special cased __import__()). Builtin Functions: Compiled code, to be run on the processor itself. Currently, we don't make a distinction between the two types of Python functions - we do exclusively Application Level functions. To do this we need to distinguish between the two. Therefore I propose that even in the TrivialObjectSpace we have special function objects. These can be just a simple wrapper around the host function objects to mark them as Application Level functions, as opposed to the unwrapped Interpreter Level functions. I think the wrapping can easily be accomplished in the MAKE_FUNCTION opcode. Does any of this sound reasonable? I tried to explain it well, but I'm quite sure I failed, so if you have any questions, please ask. -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?promo=380455
roccomoretti@netscape.net (Rocco Moretti) writes: [...]
Which sort of leads me to the reason I got on this train of thought. Over the past couple of weeks I've been trying to fix the remaining bugs in the trivial object space. Some of them seem to stem (at least in part) to the lack of a separate sys/builtins module for the application level code. (As was mentioned earlier by mwh). I've attempted to fix it by special casing the builtin __import__(). However, in order to do so, __import__() needs to be able to call out to interpreter level python functions. With the current TrivialObjectSpace, that's impossible as all python functions are run through the pypy interpreter.
Yes! I ran into this a few weeks back but then forgot exactly what the issue was :-( [...]
Does any of this sound reasonable? I tried to explain it well, but I'm quite sure I failed, so if you have any questions, please ask.
No, your description of the problem and solution made much sense over here. Are you coming to the sprint in May? Cheers, M. -- I also fondly recall Paris because that's where I learned to debug Zetalisp while drunk. -- Olin Shivers
Hello Rocco, (Firstly, sorry for the lack of answers to your contributions; you seem to be the most active person on pypy right now...) On Sun, May 04, 2003 at 04:17:34PM -0400, Rocco Moretti wrote:
I think it may be worthwhile to extend the concept of Object Spaces to the bytecode and sourcecode levels. (Provisional names: BytecodeSpace and SyntaxSpace.)
Ok. It makes sense. I should write a bit more about what I intended to use ObjectSpaces for, though, and see how explicit Bytecode/Syntax spaces fit in the picture. I promize I'll. In particular, I don't think about ObjectSpaces as controlling spaces, as you do, so there is some idea matching to do there :-)
If accepted, one change that should be made is to shift the function call semantics in the object space to have an explicit execution context as a parameter, so that it is clear that the ObjectSpace is controling execution.
That's not clear, because almost any other operation could indirectly do a function call (e.g. hash() calling the class' __hash__() method).
(...) __import__(). However, in order to do so, __import__() needs to be able to call out to interpreter level python functions. With the current TrivialObjectSpace, that's impossible as all python functions are run through the pypy interpreter.
Yes; we miss a way to call interpreter-level functions from application-level ones (the CPython's "builtin function objects"). We could take a broader point of view here, and use the separation between function objects and code objects. We could have several types of code objects, each one corresponding to a kind of function that you list: bytecodes, built-in (i.e. interpreter-level), compiled machine code... The (single) function object type would have the role of the interface, allowing introspection -- which is a nice thing to have, CPython's built-in functions lack that -- whereas the various code object types would correspond to the various ways of implementing a function. Come to that, these ways could be tied to various BytecodeSpaces -- a concept we could rename ExecutionSpace, maybe ? Executing a function object would then be done by collecting the arguments based on the signature (which would be published in the function object), which would result, say, in a single dictionary (the "locals"); then we call "f.func_code.execute(globals, locals)". What do you think about it ? Armin
participants (3)
-
Armin Rigo -
Michael Hudson -
roccomoretti＠netscape.net