Aurélien Campéas <[EMAIL PROTECTED]> writes:
> Hello, pypy people,
>
> Armin Rigo a écrit :
>> Hi Boria,
>> We are indeed starting to think about more focused research areas in
>> PyPy. For example, along these lines, we will need more work on
>> compiler optimizations and generation of code for various architectures,
>> both either statically or just-in-time. More along the lines of
>> interpreters and virtual machines, we could start investigating new
>> aspects that would be useful to code into the interpreter or the
>> translation process: continuations, persistence (either dumping a
>> whole-process image or something more fine-grained), security (running
>> code in a sandbox), and much more, all of which is hinted at in some
>> documentation on Codespeak. Finally, there is also the idea of
>> supporting other dynamic languages than Python by writing an interpreter
>> for them in PyPy.
>
> I have been looking into pypy for a few days, and trying to understand
> how to make the Lisp backend work.
Cool!
> I now understand that due to pypy heavily layered nature, it is
> possible to use a language like lisp, as a target, at different
> levels. For instance, bytecode interpreter (by providing a proper set
> of functions to handle the bytecodes ?), or compiler (by translating
> the function graph into low-level lisp). Right now, I am sticking with
> the second way, as it was started in gencl.py
>
> (btw, one question that is not clear to me is about the function graph
> : does it contain python or rpython opcodes ?)
Um, neither. It roughly goes through three potential stages:
unannotated SpaceOperations, annotated SpaceOperations and finally
LowLevelOperations. I think a lisp translator would probably want to
work with annotated SpaceOperations; LowLevelOperations would be too
low level (probably :).
> I am also thinking about another possibility (wrt your last sentence)
> : translating directly the parse tree into high-level lisp. Maybe this
> idea is nonsense.
It's not necessarily nonsense, but it's not really The PyPy Way.
> In fact, the distance from de-sugared python to the opcode is
> unknown to me (even though I suspect there is no 1:1 mapping between
> the two). Whatever, that could be the start of a strategy to
> translate python towards other high-level languages (ruby, or js as
> in the other thread) without paying the full price of opcode
> interpretation in the target (that is : parts which are semantically
> similar could be easily translated, others would be -costily-
> emulated).
Thing is, I don't know how feasible this is. It's pretty hard,
without some kind of type inference, to translate, say this Python:
a + b
into anything significantly more efficient than this Common Lisp:
(py:add a b)
And making type inference possible is what RPython is all about.
You could make #'py:add a generic function and see if a given CLOS
implementation is fast enough to give a useful speed (but I think the
coercion rules would probably drive you insane first).
Cheers,
mwh
--
ARTHUR: Yes. It was on display in the bottom of a locked filing
cabinet stuck in a disused lavatory with a sign on the door
saying "Beware of the Leopard".
-- The Hitch-Hikers Guide to the Galaxy, Episode 1
_______________________________________________
[email protected]
http://codespeak.net/mailman/listinfo/pypy-dev
