[pypy-dev] Re: Project suggestions

[Samuele Pedroni]

Aurélien Campéas wrote:

> 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.).
>
but a and/or b  could be instances of a user defined class.


> 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.
> _______________________________________________
> pypy-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/pypy-dev