[pypy-dev] Questions for Armin

[Bengt Richter]

At 10:50 2003-01-19 -0800, Armin Rigo wrote:
>[...]

>Yes, I think that we should try to unify the idea of function object vs code
>object in Python with other similar ideas used internally in CPython.  For
>example, built-in function objects have a pointer to a PyMethodDef
>structure --- we find again the distinction between the "callable
>front-end" object and the "implementation-description" structure.
>
>Ideally, we should have only one all-purpose "function" object type, which
>holds things like argument names and default values, and any number of
>"implementation" object types, of which Python code objects would be one
>example, and PyMethodDef-like objects another.  This would let us add other
>ways to implement functions, like Psyco-emitted machine code objects.
>
>Sometimes I wonder whether I should raise the question in python-dev.  It
>seems to me that it helps in various places, e.g. in the help() mecanism which
>currently cannot guess the argument list for built-in functions.  Well, I
>cannot see how to make it 100% compatible with existing code...

ISTM there is a general concept of dynamic representation management (Python
can give DRM a new meaning ;-) coming out of the mist. In C, type vs representation
is almost 1:1 (i.e., type names identify memory layouts with bits and words etc),
but with Python and psyco there are multiple ways of physically representing the
same abstract entity. I'd like to push for separating the concepts of type and
representation better in discussion.

What I'm getting at is separating "representation-type" from "abstraction-type".

E.g., a Python object pointer in C may implicitly encode an abstract tuple of
(type, id, value) or class PyPtr: __slots__ = ['oType', 'oId', 'oValue']
and we can discuss separately how to pack the info of the abstraction
into a 32-bit word with huffman tricks and addressing of type-implying
allocation arenas etc., or whatever. But maybe there's another level.

I'm wondering whether the most primitive object representation should
have a slot for an indication of what kind of representation is being used.
E.g.,

class Primo:
    __slots__ = [
        'abtraction_type',      # might say integer, but not int vs long vs bignum
        'entity_id',            # identifies abstract instance being represented
        'representation_type',  # implies a representation_interpreter, maybe CPU
        'representation_data'   # suitable for representation_interpreter to find it
    ]

In other words, multiple Primo instances with the same entity_id could be
specifying multiple abstractly equivalent but concretely different representations
of the same object, e.g., a particular integer being represented in various ways,
maybe even as machine code to move a particular represention from one place to another.
Entity_id might be encoded as a chain of pointers through sibling Primo instances
representing the same abstract instance entity.

I think there can also be representation_types that are partial representations,
something like a database view, or a C++ pointer cast to refer to data members of
a base class part of an instance representation.

This brings up relationships of multiple representations when they diverge from
1:1 representations of the full abstract info. Any full and valid representation
is abstractly equivalent to another, but if one representation is updated, siblings
must be invalidated or re-validated (some "view" might not be affected, another
representation might be easy and worthwhile to update, like a small part of a
complex object, but others might be cheaper to mark for disposal or lazy update).

ISTM Python involves multiple concrete representations of types while also trying
to unify the abstract aspects, and Psyco only adds to the need for a clear way to
speak of Dynamic Representation Management (not Digital Rights Management ;-) issues.

I hope I have triggered some useful thoughts, even though so far I only know of
Psyco indirectly from these discussions (will try to correct that sometime soon ;-)

Regards,
Bengt Richter