Robert Bradshaw wrote:
> On Jul 23, 2008, at 2:59 PM, Dag Sverre Seljebotn wrote:
>
>> - Temps can be retrieved as a typed Entry instance, using the
>> following
>> call: Symtab.new_temp(type). No releasing is needed, and it can be
>> used as
>> a regular Entry. *However*, it is required that each node registers
>> the
>> temp entries it is using in a list self.temps. (If you wondered, this
>> requires that the temp currently stored in result_code for temp
>> exprnodes
>> would show up in the temps list of the _parent_. However we can add
>> more
>> conventions so we don't have to do this (like, a combination of
>> self.is_temp and self.result_entry would count as a registration in
>> parent(self).temps, all that is required is that the transform
>> mentioned
>> below can somehow understand what is going on.)
>
> This is starting to sound a little confusing (not that the current
> system is totally straightforward, and I really don't like the fact
> that we're just passing strings around). Also, in general I'd rather
> have things worry about going down the tree instead of up.
Yes...this was supposed to be the nested expressions explanation you
sought... I'll give an example (and start again, so strike the above):
print A * B
where A and B are further nested expressions (all Python types). Then the
MulNode would require two distinct PyObject temps to do its stuff, since B
can't very well go on to use the temps that A stored its result in, but it
can use any other temps that A used as part of a temporary calculation.
Something like this would be the simplest:
- self.temps contains the temps that occure in the calculation that single
node performs. During resolving, these temps are locked so that children
nodes cannot used them, but unlocked so that sibling nodes can use them.
- This requires that the caller node allocates the temps the children need
for their result.
However it could be tricky for the caller to do this last step. So we can
do something like this:
- self.temps: Temps needed to do "my own" calculations. Temps here are
allocated for the subtree that self is the root of.
- self.result_temp: A temp I allocated to store my result in, which I give
up and which the parent is going to use. These temps are allocated for the
subtree which the parent is the root of.
However, if we can refactor stuff so that the second line here isn't
needed, great!
Anyway how we do it, the important core principle is the following:
- Temps should be inspectable/modifyable data, rather than acquired
through call-chain-based calls; in order to make transforms using temps
feel very natural and in order to allow "code analysis algorithms" to
inspect and juggle with the temps.
As long as we get from "imperative" to "declarative" temp programming, I
don't care particularily much which conventions for declaring them are
chosen.
>> - An immediate consequence is that except clauses get an exact list of
>> temps to decref (within the set of temps using the new system)
>> rather than
>> the current shotgun approach which is suboptimal (as if it
>> mattered...)
>
> Right now it's pretty tight, it only tries to decref the temps that
> could have been set in the block, depending on where the error is.
No, this is wrong, unless you improved this recently. Try
def f():
x = 4
x = (x ** (x * (x - (x - 2)))
try:
print x
except: pass
The point is, the except clause takes all free temps after the temp
analysis of the body, which might well come from code before it. (Of
course this is possible to fix within the existing framework so this is
not important.)
Dag Sverre
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
