[pypy-dev] Restricted language
Christian Tismer
tismer at tismer.com
Sun Jan 19 15:16:55 CET 2003
Hi Holger,
> [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
>>questions.
>>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.
No, this is great.
These things need to be discussed and we need
to agree on a path to go.
Interestingly, your opinion is quite different
from Armin's, and the latter brought me to ask
these questions.
[switch and such]
> Maybe make a list with 256 entries and use the bytecode
> as an index to get to a frame-method (store_attr etc.)?
Sure, I know all the possible variants, the question is
whether we like it or not.
If we are recoding Pythpn in Python, then with the
final idea in mind, that in some future, this might
become the real implementation of Python.
But then, it should not look worse than in C.
...
>>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?
Try to re-code some C code of the interpreter and
the builtin objects into Python.
After the third work-around to some C construct,
you begin to ask for more expressive constructs.
Instead of upgrading to better abstraction, I find
myself emulating C constructs.
This is not what I wanted.
<snip/>
>>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.
I understand you approach. But here we begin
to see conflicting ideas.
Citing Armin:
"""
(1) write a Python interpreter in Python, keeping (2) in mind, using any
recent version of CPython to test it. Include at least the bytecode
interpreter and redefinition of the basic data structures (tuple, lists,
integers, frames...) as classes. Optionally add a
tokenizer-parser-compiler to generate bytecode from source (for the first
tests, using the underlying compile() function is fine).
"""
...
> Redoing the basic types can be deferred IMO.
> Basically we need to do typeobject.c in python, right?
I thought so, too, but I'm not sure if my
overview of the whole thing is good enough
to judge this early.
...
>>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.
...
I can't decide here. Need Armin's input, whether
it makes sense to postpone the detail problems
in the beginning. This surely gets us a simple
start, but I hope it will not hinder us from
tackling the real problems.
A Python interpreter in Python is not a real problem.
But hopefully a goot start to tackle them.
> 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,
> whatever).
Ok. I'm eager to hear what the comments will be :-)
> 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.
This is the "world on the wire" problem.
In a direct mapping, back to C code, we could
simple repeat the Null-check strategy as it
is now. See "From PyPy to Psyco", (3a).
In the case where we need to run interpreter Python
from Python, we have to emulate exceptions in a way,
and I think we cannot "borrow" them, but we need
to interpret them ourselves.
If you look at the eval_frame code, there we already
have to handle the block stack, so we can do our
own exceptin handling as well.
There is one problem with "borrowed" objects:
If you have a dictionary for instance, which is not
implemented by our Python, but from the standard,
then this might raise exceptions, which we have
to catch and turn into our emulated exceptions.
Again the big picture:
----------------------
I don't want to disappoint anybody, but please don't
think the initial Python-in-Python interpreter is
such a big deal. It is the tip of the iceberg.
IMHO, the real hard work is to re-write the whole
C library. It is a major subject of the project to
turn that into something more flexible, and this
is the real target.
Whatever path we choose, we need to ensure that
we find a connected path to that goal.
So what I'm trying to do is to do tiny proof-of-concept
things, and try to build a chain of refinements, which
leads to a stepwise implementable final project.
We need to break the C barrier as early as possible,
or I can's see how Python can get rid of CPython.
cheers - chris
--
Christian Tismer :^) <mailto:tismer at tismer.com>
Mission Impossible 5oftware : Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9a : *Starship* http://starship.python.net/
14109 Berlin : PGP key -> http://wwwkeys.pgp.net/
work +49 30 89 09 53 34 home +49 30 802 86 56 pager +49 173 24 18 776
PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04
whom do you want to sponsor today? http://www.stackless.com/
More information about the Pypy-dev
mailing list