[Pyrex] EasyExtend meets Pyrex

[kay schluehr]

Greg Ewing schrieb:

> kay schluehr wrote:
>
>> Unfortunately I don't know if there is an elegant way of 
>> compiling/transforming the list shaped nodes such that they Pyrex 
>> compiler can handle them. A back-transformation from a constructed 
>> Pyrex parse tree to source code is feasible but it seems to be 
>> excessive to me.
>
>
> Constructing a Pyrex parse tree directly is possible, but
> you'll have to study the source quite a bit to find out
> how to do it. The parse tree node classes are defined in
> Pyrex.Nodes and Pyrex.ExprNodes. You might also want to
> look at Pyrex.Parsing for hints on how to put them together
> to represent Pyrex source code constructs. Then you'll
> also have to look at Pyrex.Main and find a way to bypass
> the parser and inject your parse tree into the compilation
> process.
>
> I'll leave it up to you to decide whether that's less
> work than just generating source. :-)
>
> -- 
> Greg


Hi Greg,

i see. The ExprNode generation that is based on a PyrexScanner object 
must be replaced by a similar creation process that is triggered by an 
EasyExtend parse tree. I guess this would be feasible but I'm not sure 
about the details. Otherwise backtranslation to source code is 
technically trivial and can always be done. It is just not that I'm a 
strong adherent to the Unix philosophy and seek for a more intimate 
component coupling ;)

A disadvantage of the approach I have obviously overlooked in my 
enthusiasm yesterday, are the limitations of Pyrex relative to Python, 
which might not be that severe when Pyrex modules are handcoded but are 
a caveat for automatical translation. Modules would have to be ripped 
off and splitted into translateable and intranslateable parts. So a 
Module M would be considered as a product M0 (x) MT where M0 defines 
intranslateables relative to a "native translator" NT ( e.g. Pyrex, 
RPython, Shedskin etc. ) , while MT contains translateables. Moreover M0 
defines stubs of functions which are implemented in MT. The split has to 
be performed on CST level. The source versions of M0 and MT will be pure 
runtime constructs. M0 will be compiled to M.pyc and MT to e.g. 
M_pyrex.pyd depending on NT. Import of the extension module M_pyrex.pyd 
by M is not reflected in M.py but in M.pyc only. I for my part suggest 
an API for enabling "clean splits". They could be established in a 
broader context in which "refactoring moves" moves are defined ( but 
refactoring moves also should respect semantical insignificant blanks, 
newlines etc. of sourcecode that are yet stripped off during tokenization ).

Regards,
Kay