-----Original Message----- From: Armin Rigo
*All* types are expected to be computed during type inference. So don't even say that W_ListObject.objarray is a list of wrapped objects or Nones -- this can be figured out automatically.
<snip>
Consider for example the case of *two* different implementations (that would both appear as having the 'int' type to users). Say that one is like Christian's W_IntObject+r_int, and the other one can only encode small, tagged integers. The choice to use one or both representations in an actual C implementation must be made by the RPython-to-C translator, and not in the object space.
<snip>
The original intent of classes like W_IntObject was "one class, one implementation", and I think that we must stick to that idea because these classes are what are used for the multiple dispatch routines.
Can you point out some idea about the *work* of the RPython-to-C translator? I can only imagine what I pointed out in the last email... <FOGGY> - The RPython-to-C translator check the source code of the application for *static* *compile-time* optimization. - The RPython-to-C translator run the application under some objectspace. If I've understood well the idea, the application is the pypy-interpreter PLUS the application... - It performs introspection and optimize changing on-the-fly things. Some W_XXXObject is replaced with other, probably more *restricted or suited to the target the specific code emission*, ex the W_IntObject+r_int. Donno if this phase is to be done, I guess is an *additional* layer but remembering the discussion about the stack dept calculation, this can be the way to tell if all in the application is ok and aid the compiler... - loop analysis on even-more-restricted source - Finally emit C code for that specialized-parts, for example code that mimics current CPython functions for pypy-part of the interpreter, or code that recall the specialization done by psyco. </FOGGY> Paolo Invernizzi