[pypy-dev] Re: Project suggestions
aurelien.campeas at free.fr
Sat Oct 1 21:58:00 CEST 2005
Armin Rigo a écrit :
> Hi Aurelien,
> On Sat, Oct 01, 2005 at 02:44:50PM +0200, Aur?lien Camp?as wrote:
>>I would tend to provide a huge prelude implemeting a close aprox. of
>>those in CL (it is my plan).
> Yes, this would be possible. I suppose even dark corners like
> dictionary with user-specified ways of computing the hash of keys could
> be done this way.
Yes, thru sxhash probably
Well, rarely used obscure corner cases are not my priority, I need to
get going on to more basic stuff :)
>>>and then there are
>>>rather more obscure annotations like SomePBC() that are quite involved.
>>>Just to frighten you a bit, you'd also need at some point to do
>>>something like pypy/rpython/normalizecalls.py :-)
>>I can't really be frightened by something I don't know about nor
> That's the problem, I suppose. RPython is larger and more delicate than
> it seems to be at first.
It seems also very entangled into various parts of pypy. And even after
having read the doc again, i still don't really get its justification
is not too clear for me).
> After a lot of trashed efforts in GenC, we
> eventually found out the correct approach, which is:
>>>What we have in mind is to support targets like CL by a modified RTyper
>>>(pypy/rpython/r*.py); it means that there would be an additional
>>>processing step between the graph-with-annotations and the CL backend
>>>which would simplify the graphs and replace complex operations and
>>>annotations with more primitive ones. This will make the task of the
>>>backend far easier.
> Compare the flow graphs after annotation and after rtyping (e.g. with
> translate_pypy.py targetrichards.py --annotate versus --rtype). The
> latter are in a very controlled format, using strict C-like types
> (structures and arrays and nothing more). Even the constants are
> prebuilt structures and arrays. It is the rtyper that does the hard job
> of converting from the annotated graphs to these low-level graphs.
But never mind, I don't want to work on a low-level graph ! Right now
i'm investigating interpreter/transformer, stablecompiler and friends to
see if it is possible to get an early, unannotated, unrestricted, and
close-to-python parse-tree that could undergo an almost trivial
tranformation towards sexps (and then, a prefix python notation).
> For backends that are a bit higher-level than C, we need some
> intermediate solution that uses some parts of the rtyper and some parts
> of the direct code generation you have in mind. That's also something
> we should discuss at the Paris sprint with Bert, as it is what a
> Smalltalk back-end should need as well.
> But for now I suppose that writing the direct code generation for the
> easy parts is the best way to start.
Yes, i'm sorry, the rpython stuff is currently beyond me and will remain
so for a while. The current value of pypy for me is the existence of a
nice python source code -> AST transformer usable from python. As a
final by-product of this work, i'd like to get an embedded-in-lisp
Someone earlier said it was not a goal of pypy to proceed like that.
Anyway, thanks for the snippets of light,
More information about the Pypy-dev