[pypy-dev] Builtin types

[Bengt Richter]

At 20:03 2003-01-27 +0100, Samuele Pedroni wrote:

>----- Original Message -----
>From: "holger krekel" <hpk at trillke.net>
>To: "Armin Rigo" <arigo at tunes.org>; <pypy-dev at codespeak.net>
>Sent: Monday, January 27, 2003 6:00 PM
>Subject: Re: [pypy-dev] Builtin types
>
>
>> [Armin Rigo Mon, Jan 27, 2003 at 01:18:00PM +0100]
>> > Hello,
>> >
>> > On Fri, Jan 24, 2003 at 05:48:42PM +0100, Samuele Pedroni wrote:
>> > > OTOH I think a higher level of abstraction is necessary to targert more
>general
>> > > backends.
>> >
>> > I agree with Samuele that we should not focus on ctypes or any other kind
>of
>> > structs right now.  For all of ctypes' power I believe that it is not
>central
>> > to Python-in-Python.  This will become important later, when we target C.
>>
>> how do you intend to use any of the existing C-libraries, then?
>> Rely on CPython to provide the binding?
>>
>> I think that progressing in the ctypes direction can happen in
>> parallel with Python-Core pythonifications.  Beeing able to make
>> C-library calls (like File-IO) without specialized intermediate C-code
>> does seem like an important feature.
>
>The point was whether you want your builtin types "abstractions" to be directly
>ctypes based.
IMO (FWIW) no, but OTOH I think the functionality is needed. So in order to get the
"abstractions" right, perhaps a thin wrapper around ctypes would be a practical
near-term step. Then the question becomes what the "abstractions" involved in
calling on ctypes really are, and what that thin wrapper should look like.
It is easy to draw a line and say crossing it is an OS API call, but I am thinking
the PyPy situation is more complex than that, and instead of lines, a foam of nesting
bubble boundaries may be needed ;-)

>Or reformulated as a question:
>
>Is a goal to target some reasonable other virtual machines /languages/object
>models  as  execution substrate?
>(or do you want to limit yourself to implement some C/native code
>reedition/evolution of CPython)
I would think a goal would be to retain the options, if at all possible.

ISTM there is also the possibility of source-source down-translation to a subset
of the same language, as an end as well as a bootstrapping mechanism. E.g., a common
subset of Python 1.5.2 and 2.2.2, viewing a Python 1.5.2 as a virtual machine
operating on source byte streams, analogous to ceval.c operating on byte codes.

All of the above are really abstract views of what a CPU is doing at any given
moment in some context, since a CPU is always doing the work with raw bits in
registers and on-chip cache, getting and disposing of bits by electrically
signaling other devices (mostly memory chips).

I am trying to get my head around this in terms of mega and nano views of
CLLG -- i.e., compile-link-load-go and associated resource management and
dispatching of control. Somehow I suspect there has to be abstractions for
these things expressible in the language in a more fundamental way, that
reflects cleaner and more comprehensive abstractions than a single-boundary
interface of OS api and/or ctypes calls. But I'm not there yet, and not
advising anyone to hold their breath. Just offering preliminary thoughts
for the conceptual pot-luck ;-)

>No is obviously a fine anwer.
>
>OTOH I think it is important to answer better sooner than later, because if one
>thinks that simply because this is (some) Python in Python the problem is
>automatically solved, he is having the wrong intuition.
There is a lot to think about, but it is fun ;-)

Best regards,
Bengt