[pypy-dev] Re: Project suggestions

[Aurélien Campéas]

Armin Rigo a écrit :
> Hi Aurelien,
> 
> On Sat, Oct 01, 2005 at 09:58:00PM +0200, Aur?lien Camp?as wrote:
> 
>>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.
> 
> 
> That's rather a by-product.  The basic source code -> AST transformer is
> already in the standard Python library, where it's available with a
> simple 'import compiler'.  We just cleaned up a bit (or rather a lot, as
> it was quite buggy).

Well I'm glad Pypy brings that :)

> 
> 
>>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.
> 
> 
> I'm sorry I scared you off flow graphs.  

You didn't ; only pointed compactly some of the complexity one perceives 
reading the code. I need an understandable entry point anyway, so 
beginning with the "easy" stuff and rediscovering already known mistakes 
is somewhat unavoidable ; it'll help to understand the rationale behind 
Pypy's architecture.

> I can only refer you again to
> Michael's e-mail earlier in this thread.  People commonly underestimate
> the problems he mentioned; this has led to a number of projects of
> Python-in-Insert-Language-Here, all aborted for basically the same
> reason: the basic built-in types and semantics are easy enough, but
> supporting the complete Python semantics is rather more involved and
> impossible to add incrementally on top of a simple and fast approach.

I guess supporting completely every quirk of one "real world" 
programming language from another is never a trivial task.

> PyPy is born from realizing this; we (painfully) wrote the complete
> semantics once and won't start duplicating that logic.
> 
> Instead, we rewrite support for the infinitely simpler RPython
> semantics, and even then we try to share code between back-ends (which
> is the purpose of the RTyper).  Using the RTyper is not mandatory for
> back-ends, but you definitely cannot analyse RPython code from the AST
> for the good reason that it's a language without source code.

Can you expand on this ? I tend to see the AST as a programmatically 
manageable representation of the source code. Is this expectation wrong ?

> 
> Anyway, instead of hand-waving, I guess we really need to implement a
> non-C back-end soon enough, just to show that we *can*.  It's the whole
> point of the rather complicated translation architecture we've built.
> 

I am glad it will be possible to see it at work. The knwoledge embodied 
in Pypy for sure is not easy to convey without a nice demo (and I 
haven't yet dared look at the C backend).

Cheers,
Aurélien.