[pypy-dev] Re: Project suggestions

[Aurélien Campéas]

Michael Hudson a écrit :
> Aurélien Campéas <aurelien.campeas at free.fr> 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 :).
> 

Ok, thanks :)
But then, I still don't get completely the relation between python, 
rpython, and the three potential stages of the function graph (probably 
I have to reread again all the doc on codespeak)

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

ok

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

The mere fact that it will be compiled will make it more efficient I 
guess. I mean, not on CLISP, but with a real lisp compiler.

> 
> And making type inference possible is what RPython is all about.

Sure, but then, it is a restricted subset of Python, and I like python 
completely unrestricted ;)

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

In this case, CLOS would add overhead. In fact the python add operator 
(and some arith. ops) seems close enough to the lisp one that one can be 
tempted to translate in the lisp equivalent with only minor adaptation 
(like the printer appending an "L" on bignums, etc.).

I am not sure I would use CLOS at all, in fact (at least for a first 
attempt at producing a lisp backend). BTW, what's this "insanity with 
coercion rules" that you mention - can you expand a little on this ?

> 
> Cheers,
> mwh
> 

Many thanks,
Aurélien.