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.,
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
From: "Bengt Richter" <bokr@oz.net> the 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.