[pypy-dev] Annotating space status
pedronis at bluewin.ch
Wed Jul 2 23:30:40 CEST 2003
At 15:18 02.07.2003 -0400, Guido van Rossum wrote:
> > the problem is our fix-point condition which is mostly based purely
> > on types, and that we are trying to have it both ways, doing some
> > mixture of constant propagation (normal eval) and type propagation,
> > if you consider code like this:
> > x = 0
> > while True:
> > x = x + 2
> > type propagation can end, but constant evaluation will give an
> > infinite loop.
> > So we should clarify what we really want.
> > One possibility is optinally instead of using types to decide
> > fix-points, we stop if some bytecode (position) has been encountered
> > more than N times.
>Right. We could differentiate this by using the differentiation of
>object space and execution context for evaluation of internal helpers.
>Those helpers want constant evaluation, and they already get a
>different object space (a subclass of the annotating object space).
>The space controls the execution context, and the execution context
>controls whether we check for fix-point conditions.
>The "real" code would continue to use the "normal" annotation space
>and would do full type propagation.
another problem is that for the momement we unify between different
invocation of a same function but we don't reflow the information trough
the entire call-graph, we just traverse some part of it as needed:
r = self.codetest("def f():\n"
" x = g(1)\n"
" y = g('1')\n"
" return x\n" # vs. return y
" return y\n",
in the 'return x' case r is W_Constant(1)
in the 'return y' case r is W_Anything()
this is sort of bogus, and here too we should clarify what we want:
- reflow type info through the call-graph somehow (this means more code
complexity) and get in both cases W_Anything()
- don't unify beetween different invocation of a same function: maybe
that's enough for our purposes and get W_Constant(1), W_Constant('1')
More information about the Pypy-dev