[pypy-dev] Restricted language
hpk at trillke.net
Sun Jan 19 13:45:10 CET 2003
[Christian Tismer Sat, Jan 18, 2003 at 11:03:34PM +0100]
> in order to start considerations about how to
> implement Python-in-Python, here some initial
> Yes, we should begin with the RISP processor :-)
> (Reduced Instruction Set Python).
cool, we are getting to implementation strategy!
Hopefully you don't mind if i comment even i am
not Armin :-) I'm curious about his oppinion
on this, too.
> There are some issues where I have to navigate
> around in my little tests that I've done already.
> One thing is the lack of a switch statement in
> Python, which either leads to zillions of elifs,
> or to the use of function tables and indexing.
> We should come up with some "how to do this".
Maybe make a list with 256 entries and use the bytecode
as an index to get to a frame-method (store_attr etc.)?
A specialised compiler could later inline the method
bodies and turn any attribute access on 'self' (the
frame object) into a local name operation.
So there would be the first restriction: always use 'self'
to refer to the instance within a frame method.
> Another thing is common for-loops in C.
> Almost all of them which I tried to translate
> into Python became while-loops. Is that ok?
yes, why should it not?
> Data types.
> How do we model the data types which are used
> internally by Python? Somebody already showed
> a small Python interpreter for Python 2.0
> (very sorry, I can't find who it was),
I think several people mentioned doing something like
this. Look at
where i gathered two links about python-in-python
implementations. If i forgot anyone: it's a wiki
so just insert a paragraph about your stuff.
Never forget to describe a link!
> was implemented on top of basic Python objects.
> This was a nice attempt and makes sense to start
> with. But I gues, for a real Python in Python,
> we also need to re-build the data structures
> and cannot borrow lists, tuples and dicts and
> "Lift them up" into the new level.
I wouldn't do this for starters.
> Instead, these need to be built from a minimum
> Python "object set" as well.
> How far should we go down?
Redoing the basic types can be deferred IMO.
Basically we need to do typeobject.c in python, right?
> I was thinking of some basic classes which describe
> primitive data types, like signed/unsigned integers,
> chars, pointers to primitives, and arrays of
> primitives. Then I would build everything upon these.
> Is that already too low-level?
> Do you think this should be started using the builtin
> objects right now, and these should be replaced later,
> or from the beginning?
replaced later IMO. First get a working interpreter
and eliminate anything that stands in the way.
> How far should it go: Are we modelling reference
> counting as well?
I'd try without. For the time beeing, CPython
does it for us until we come up with a scheme.
But the scheme is best experimented with when
we have a working interpreter.
> So I guess we are not fine by just repeating the
> C implementation in Python, but we need some kind
> of "upsizing" the algorithms, away from a flat
> write-down in C, up to a more abstract defintion
> of what we want to do.
I regard a python-in-python interpreter as Pseudo-Code
which can be turned into other representantions (in C
or another bytecode machine) by an appropriate compiler.
Using Python to describe the abstract descriptions
makes sense to me. So we eliminate any C-isms
(like switch statements, reference counting, signalling
exceptions by NULL returns etc.).
> Very many things are done in a specific way in C, just
> because of the fact that you have to use C. But when
> I know I have Python, I would most probably not use
> C string constants all around, but use Python strings.
> It is C that forces us to use PyString_FromString
> and friends. Do you think we should repeat this in
> the Python implementation?
No. The goal is: get a working interpreter in python
running on CPython. An interpreter where you can run
the unittests against. Don't care about any low-level
stuff. That is handled by CPython and later on will
be handled by custom compilers (to C, MMIX, assembler,
I am still thinking about Roccos issue of how to
"differentiate" host system (CPython) exceptions from
exception of the code we interprete in python. My first
take is to catch any exception, rewrite the traceback
information (using the python-frames) and reraise it.
The exceptions must look the same as if i executed with
all the best,
More information about the Pypy-dev