[phc-general] Why isn't Tree_transform::pre_statement()implemented

Satyam Satyam at satyam.com.ar
Tue Aug 1 10:42:57 CEST 2006


----- Original Message ----- 
From: "Edsko de Vries" <edsko at phpcompiler.org>
To: "Satyam" <Satyam at satyam.com.ar>
Cc: <phc-general at phpcompiler.org>
Sent: Tuesday, August 01, 2006 9:59 AM
Subject: Re: [phc-general] Why isn't 
Tree_transform::pre_statement()implemented


> On Mon, Jul 31, 2006 at 06:40:13PM +0200, Satyam wrote:
>> It works for me with the Tree_visitor, but it does not with 
>> Tree_transform.
>
> Yes, that is because Tree_transforms don't have generic methods. From
> tutorial 3:
>
>  (...) Tree visitors can only inspect and modify in; they cannot
>  restructure the tree. In particular, we cannot replace *in by a new
>  node. For this purpose, phc offers a separate API, the tree
>  transformation API. It looks very similar to the tree visitor API, but
>  there are two important differences. First, the pre and post methods
>  can modify the structure of the tree by returning new nodes. Second,
>  there are no "generic" methods in the tree transform API.

What do you mean by 'generic'? How would I know which are 'generic' methods 
and which aren't?  After all, they are all declared.  It could be useful if 
those that do not work were not declared.

> So, it is
>  not possible to define a transformation that would replace all
>  statements by something else. (It is not clear how that would be
>  useful, anyway.)

Well, I can tell you why it would be useful to me.  I actually need to 
insert a statement whenever I find a certain method_invocation, that is, 
when I find a particular call, I need to insert some other statement.  I 
cannot modify the called method since it might be in an include file.   The 
pre and post method_invocation give me a one to one replacement, I get one, 
I can replace it by another, but can't replace them by two.   So, I went up 
one level in the tree and pre and post statement (supposedly)  take one 
statement and allows me to return a statement list, so there I can pick my 
method invocation and return my preparatory statement and then let the 
original method go through.  Now, what I am doing is taking a 
statement_list, looping through the statements, matching them against the 
method_invocation I'm looking for and returning a longer list, with added 
statements.  So, there is some usefulness to it.

Nevertheless, I do find a problem which I'm after right now and it is that 
the tree-traversal algorithm seems to keep traveling over the original tree, 
not the modified one.  Not sure on this one, I'm looking into it, so far I 
am looking into some strange behavior, but I'm not clear what is it, so 
don't trouble yourself with it.

>
> Older versions of phc (pre 0.1.6 I think) did not make a distinction
> between the two APIs, but then it had much more limited generic methods
> (no pre_node, for example). We considered combining both APIs into the
> one, but it leads to conceptual difficulties - so we figured that
> splitting the APIs would lead to the cleanest and easiest to understand
> API.
>

That's not a problem at all, you either modify it or not, not a problem.

Satyam


> Edsko
> _______________________________________________
> phc-general mailing list
> phc-general at phpcompiler.org
> https://altoure.vm.bytemark.co.uk/cgi-bin/mailman/listinfo/phc-general
>
> 




More information about the phc-general mailing list