[pypy-dev] Restricted language

Christian Tismer tismer at tismer.com
Sat Jan 18 23:03:34 CET 2003


Hi Armin,

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).

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".

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?

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), which
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.
Instead, these need to be built from a minimum
Python "object set" as well.
How far should we go down?

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?

How far should it go: Are we modelling reference
counting as well?
And since you said that whether to use reference
counting at all, or a classical GC, or object/type
tuples returned as register pairs, I'm asking how
we should do the proper abstraction?
This means clearly to me, that I should *not*
repeat the Py_INCREF/Py_DECREF story from Python,
but we need to do a more abstract formulation of
that, which allows us to specify it in any desired
way.

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 could even imagine that there are lots of other
cases where the C source code already is much to
verbose, over-specifying, and obfuscating what
the code really is supposed to do.

Would you propose to "start dumb", literally like
the C source, and add abstractions after the initial
thing works, or does this have to happen in the first
place?
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?

This is just the beginning of a whole can of worms
to be considered. Just to start it somehow :-)

all the best -- 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