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
understand ...
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
(for instance
http://codespeak.net/pypy/dist/pypy/doc/coding-guide.html#our-runtime-interpreter-is-restricted-python
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
python compiler.
Someone earlier said it was not a goal of pypy to proceed like that.
We'll see.
Anyway, thanks for the snippets of light,
Aurélien.
_______________________________________________
[email protected]
http://codespeak.net/mailman/listinfo/pypy-dev
