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.
_______________________________________________
[email protected]
http://codespeak.net/mailman/listinfo/pypy-dev
