Dag Sverre Seljebotn wrote: > I believe the following > temp refactoring is a) conceptually simple and not a big break with > current ways of doing things, b) can be made very incrementally (though > there may be inconsistencies in "how things are done" along the way), c) > is useful (at least to me).
I don't think it should be necessary to go to this much upheaval in order to make temps easier to use. All you should really need is some suitable node types to use as building blocks during your tree transformation phases. I'm thinking of something like the following: * LocalNode - an ExprNode representing a temporary local variable that is allocated using the temps mechanism. * LetNode - a StatNode that holds a list of LocalNodes and a StatListNode. It functions like a "let" statement in Lisp, i.e. binds some local variables, executes the body and then disposes of the locals. The code for the LetNode would work in a similar way to the existing code in the for-statement node and other places that use temporary locals, except that instead of a fixed set of locals, it would do it for whatever was in its list of LocalNodes. In the body of the LetNode, wherever you wanted to refer to one of the locals, you would insert a CloneNode (an already-existing node type) that references the relevant LocalNode. Then the existing machinery should do the right thing. Not knowing the result_code won't be an issue, because you're not dealing with things at that level, you're just plugging nodes together. > I think it > is ok if we agree that result_code should be refactored at some later > point if one gets the time and resources; i.e. one stores "result_entry" > and other entry references instead at analysis time and only calculate > result_code at code generation time). You really ought to look at how this is in the current Pyrex before doing anything about this. The result code is now retrieved by calling result_as(), or something else that ends up calling it, during code generation. So there's no longer a requirement to calculate the result code at analysis time -- it can be constructed on the fly at code generation time if need be. This means it would, I think, be fairly straightforward now to merge all the temp allocation/release stuff into the code generation phase, although I haven't looked in detail at what would be required. -- Greg _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
