[pypy-dev] Re: Project suggestions

Armin Rigo arigo at tunes.org
Sat Oct 1 22:23:31 CEST 2005

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

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

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.

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.

A bientot,


More information about the Pypy-dev mailing list