[pypy-dev] __builtin__ module

[Samuele Pedroni]

From: "Bengt Richter" <bokr at oz.net>
> At 08:32 2003-01-24 -0500, Scott Fenton wrote:
> >On Fri, Jan 24, 2003 at 02:48:42PM +0100, holger krekel wrote:
> >>
> >> what do you mean by this?  "everything" can always be expressed in
> >> a python function.  It's a matter of time and space so could you
> >> be more specific?
> >
> >Mostly, stuff that exists as "builtin" syntax, ie printf-style formats
> >that can be implemented "under the hood" using sprintf should probably
> >be C. "everything" can be expressed in term of my signature, I just
> >wouldn't try it if my life depened on it.
> >
> >>
> >> Anyway, I would try very hard to express all the builtins in python.
> >> And i see Thomas Heller's ctypes approach as a way to make
> >> this possible.  Before coding anything in C there must be a
> >> real *need* to do so.
> >>
> >
> >I can make chr python either way. It's a question of how "deep" we want
> >python to go.
>
> I'm thinking "depth" is a monotonic relationship among nodes along a path
> in an acyclic graph, and so far we are talking about two kinds of nodes:
> "interpreter level" and "Python level". I am getting an idea that maybe
> we should be thinking meta-levels instead of two kinds, and that in general
> there can concurrently exist many levels of nodes in the tree, all busily
> acting as "interpreter level" for their higher level parents, except for
> root and leaves. Not sure how useful this is for immediate goals, but I'm
> struggling to form a satisfying abstract view of the whole problem ;-)
> It's interesting that manipulation of representational elements in one
> level implements operations at another level, and manipulation is _defined_
> by a pattern of elements that live somewhere too. It's a subtle soup ;-)
>
> BTW, discussion of chr(i) and ord(c) brings up the question of representing
> reinterpret_cast at an abstract level. (Whether a C reinterpret_cast
correctly
> implements chr and ord semantics is a separate question. I just want to talk
> about casting a moment, for the light it may shed on type info).
>
> ISTM we need a (python level) type to (meta-) represent untyped bits. I.e.,
the
> 8 bits of a char don't carry the type info that makes them char vs uint8.
> The hypothetical meta_repr function I mentioned in a previous post does make
> use of a Python level object (Bits instance) to represent untyped bits. I.e.,
> if c is a character, conceptually: meta_repr(c) => ('str', id(c), Bits(c))
> where Bits(c) is a special bit vector at the Python level, but represents the
> untyped bits of c at the next meta-level ("interpreter level" here).
>
> An in-place reinterpret_cast from char to uint8 would amount to
>     ('str', id(c), Bits(c)) => ('int', id(c), Bits(c))
> (Assuming that in the abstract, 'int' doesn't care about the current number
of
> bits in its representation, though I'm skipping a detail about sign, which
> is an interpretation of the msb of Bits(c), so it should probably be written
>     ('str', id(c), Bits(c)) => ('int', id(c), Bits(0)+Bits(c))
> where the '+' means bit vectors concatenate. Or you could have a distinct
'uint'
> type. That might be necessary for unsigned fixed-width representations.
>
> A _conversion_ would virtually allocate existence space by also providing
> a new distinct id and copying the representational Bits (or not copying, if
> we can tag the instance as immutable for some uses). Note that you can
imagine
> corresponding operations in a different level where there's an "actual" space
> allocation somewhere in some array (Python level or malloc level ;-) and
> id indicates a location in that array, and 'int' is perhaps encoded in some
> Bits associated with the Bits of the newly allocated int representation, or
maybe
> implicit in the indication of the space array, if that is dedicated to a
single type.
> All this, too, could be represented abstractly at a level before machine
language,
> so I think a two-meta-level model may be constraining.
>
> If you look at ('str', id(c), Bits(c)) as Python-level code, it is
> a Python level tuple with a Python level string, int, and class instance.
> The whole thing only has meta-meaning because of how it is interpreted
> in a context relating two meta-levels.
>
> I.e., the interpretation itself is expressed at the Python level, but being
plain
> Python, there is a meta_repr(('str', id(c), Bits(c))) involved in the next
> level of what's happening, and so forth, until leaf representations of
machine
> code are evolved and used, IWT.
>
> Hoping I'm helping factor and clarify concepts rather than tangle and muddy,
> Bengt

I think that the untyped bit vector thing is too low level.