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

[Satyam]

----- 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 11:09 AM
Subject: Re: [phc-general] Why isn't =

Tree_transform::pre_statement()implemented


> Hi Satyam,
>
>> 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.
>
> "Generic" methods correspond to abstract classes; so, "pre_statement" is
> a generic method, but "pre_if" is not. In ast.h, class AST_statement is
> abstract (it has pure virtual methods, with that strange "=3D 0" syntax),
> but class AST_if is concrete. Or, alternatively, if you prefer to look
> at the grammar, a "generic" method is one that corresponds to a
> "disjunctive" rule in the grammar such as
>
> statement ::=3D if | .. | ..
>
> (so, a rule that lists alternatives), and a non-generic method correspond=
s =

> to a "compound" rule in the grammar, for example
>
> if ::=3D expr statement* statement*
>
> (one that lists the "contents" of the node). However, I would think it
> is intuitively clear anyway: and "if" is a "real" node in some sense,
> there really are "if" nodes in the tree; a "statement" is a more
> abstract notion; there are never "statements" in the tree (only ifs, or
> whiles, or whatever).

Got it, makes sense.

> (Hmmmm. Interesting. I was going to say that you won't find a
> "pre_statement" in Tree_transform.h, but as a matter of fact, you will.
> That is a (harmless but potentially confusing) bug and we will need to
> look at that.)

Then, yes, it would be nice if the method is not listed in tree_transform.h=
, =

otherwise you would expect it to be called.
>
> Actually, the best way to solve that problem is to go up one level to
> AST_eval_expr instead.

Yes, indeed.  What happened is that when I noticed that =

pre_method_invocation would not allow me to add statements, I thought about =

going one level up, but didn't actually check it in phc.tea, which is where =

I usually go and just out of my mind I came up with pre_statement.  Then, =

when that didn't work, I went one level further up to statement_list and at =

no time I realized that I had already jumped over eval_expr.   I now captur=
e =

eval_expr and works perfectly, thanks.

>
>> 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.
>
> If that is true, something is seriously amiss. If you can find a small
> transform that shows that behaviour, please send it to us.
>

I guess I made it as small as it gets.   The files are attached.  The .cpp =

is the transform, the .php is the source to transform and the .txt is the =

result of doing a:

../phc --run unst1.so --dump-php unst1.php

Notice that, though the PHP output is what the transformation meant, there =

is no XML dumps of the nodes within the "if", only the {echo"before"} and =

{echo "after"} nodes get visited.  So, if I wanted to change {echo "this"} =

to {echo "more" , " of ", "this"}, I wouldn't have been able to.

I admit this is a very special case because I am completely changing the =

structure of the program but, in fact, I need to do that.   The syntax of =

one of the statements of my extensions is:

tag <expr> <statement>

So that:

tag 'hello' {
    echo 'greetings';
}

would turn into:

echo '<hello';    // attributes might go here inside the openning tag, =

that's why it is broken
echo '>';
echo 'greetings';
echo '</hello>';

So the {echo 'greetings'} which is nested within the AST_tag node gets =

promoted one level  up in the tree hierarchy.

This example also shows why my compact_echo plugin is important for me, so =

that all the above gets converted to:

echo '<hello>greetings</hello>';

Anyway, I realize mine is a very special case where I am modifying the PHP =

grammar and the tree structure, which I later have to mend. Right now I am =

doing as if in this example I were to call:

in->iftrue->transform(this);

So, it is easily fixed, no big deal.

I can't think of any other specific needs, though I would assume any =

pre-compiler might do this kind of restructuring.  For example, PHP =

currently supports declare(directive) statements.   Should anyone wanted to =

create further in-house directives, chances are that the statement list =

enclosed by the directive will have to be promoted one level up in the tree=
. =

One I can think of right now is:

declare(debug) {
    var_dumps galore!
}

For the debug version, the var_dumps have to be promoted up while for the =

production version it should all go away. This could also be done as:

define('DEBUG',true);
if (DEBUG) {
    var_dumps galore!
}

Anyway, in this case, the nodes within the conditional execution directive =

do not need to be visited since they don't need to be transformed, either =

they go or they don't, which is handled at the level of the declare or if.

All these are just crazy ideas so, never mind.

Satyam





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

-------------- next part --------------
<AST_eval_expr>
	<AST_method_invocation>
		<Token_class_name>
			<value>%STDLIB%</value>
		</Token_class_name>
		<Token_method_name>
			<value>echo</value>
		</Token_method_name>
		<AST_actual_parameter_list>
			<AST_actual_parameter>
				<bool name=3D"is_ref">false</bool>
				<Token_string>
					<value>before</value>
					<source_rep>before</source_rep>
				</Token_string>
			</AST_actual_parameter>
		</AST_actual_parameter_list>
	</AST_method_invocation>
</AST_eval_expr>
<AST_eval_expr>
	<AST_method_invocation>
		<Token_class_name>
			<value>%STDLIB%</value>
		</Token_class_name>
		<Token_method_name>
			<value>echo</value>
		</Token_method_name>
		<AST_actual_parameter_list>
			<AST_actual_parameter>
				<bool name=3D"is_ref">false</bool>
				<Token_string>
					<value>after</value>
					<source_rep>after</source_rep>
				</Token_string>
			</AST_actual_parameter>
		</AST_actual_parameter_list>
	</AST_method_invocation>
</AST_eval_expr>
<?php
	echo "before";
	echo "this";
	echo "after";
?>
-------------- next part --------------
#include <phc/Tree_transform.h>
#include <phc/Tree_visitor.h>
#include <phc/process_ast/XML_unparser.h>


class Convert_html_elements : public Tree_transform {


	void pre_eval_expr(AST_eval_expr* in, AST_statement_list* out) {
		in->visit(new XML_unparser);
		out->push_back(in);
	}
	=

	void pre_if(AST_if* in, AST_statement_list* out) {
		out->push_back_all(in->iftrue);
	}
};


 extern "C" void process_ast(AST_php_script* php_script)
{
	Convert_html_elements*  che =3D new Convert_html_elements();
	php_script->transform(che);
}

-------------- next part --------------
A non-text attachment was scrubbed...
Name: unst1.php
Type: application/octet-stream
Size: 99 bytes
Desc: not available
Url : http://nova.villiros.com/pipermail/phc-general/attachments/20060801/5=
9b1b8d3/unst1-0003.obj