Hi Kay,
On Mon, May 23, 2005 at 13:39 -0700, Kay Schluehr wrote:
> Does it mean You create an RPython object that runs on top of CPython,
> but is just an RPython facade wrapped around a CPython object? So You
> have four kinds of Pythons:
>
> RPy - translateable into LL code
> APy - non-translateable but interpretable by translated RPy
> RPy* - non-translateable but consistent interface with RPy. Calls
> APy*
> APy* - not translateable and not interpreteable by translated RPy
>
> "Selfhosting" would imply vanishing RPy* and APy*. But the problem
> seems to be that selfhosting must somehow be broken because the system
> needs to interact with OS-dependend librarys. As long as You run the
> system upon CPython the problem does not occur but once You drop it, a
> kind of "extension objectspace" must be created which is translated
> into code with nice interfacing properties.
You are mostly right but 'extension objectspace' is misleading.
Object Spaces are only responsible for manipulating Python
application objects.
To get rid of 'faked' objects we need implementations for IO
access and operating system interactions. Those can sometimes
even be written in pure python (applevel) as is the case for
a preliminary version of a file object.
> RPython translations will be sufficient and another ext-objectspace is
> just useless epi-cycling?
Conceptually, we need a good concept to perform foreign
function invocation (FFI) much like ctypes or other approaches do.
However, concretely, we might at first just write some very
low-level code (even lower level than RPython) to interact
with os-level APIs and weave that into the translation process.
This is an area we are beginning to explore in more depth currently.
cheers,
holger
--
http://mail.python.org/mailman/listinfo/python-list
