[pypy-dev] Re: Project suggestions

[Aurélien Campéas]

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.