On Jul 23, 2008, at 11:40 PM, Greg Ewing wrote: > 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.
I just want to pipe up and say that putting the temp allocation/ release into the code generation phase seems extremely natural for me--more so than anything else that has been proposed. Specifically, you request a temp, use it, then release it when you're done. None of this trying to sync temps between multiple phases. - Robert _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
