[Cython] Temp framework proposal

[Robert Bradshaw]

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