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

[Edsko de Vries]

Hi Satyam,

> >and in particular section "A Subtlety" (towards the end of the
> >tutorial).  The problem you're experiencing is exactly what I've
> >tried to explain there (although perhaps I didn't do a very good job,
> >it *is* indeed a subtlety :-) If you still don't understand what's
> >happening after reading that, please do come back to me.
> 
> When I read it I couldn't figure out what was the point.  Now that it
> happened to me I see it.

Yeah, it's one of those things alright. As I say, it's a bit subtle. You
need to understand the way the tree visitor operators quite well to
understand what's going on (it certainly had me baffled for a long time
when I first ran into this problem).

> >Yes, as explained in tutorial 3, that is one solution, although the
> >better solution is to use a post-transform rather than a
> >pre-transform; but that may not be possible, depending on the
> >transform. Also, if you _are_ implementing a pre_transform, you don't
> >need to call transform; calling pre_transform is enough.
> 
> Indeed, I thought I needed to pick pre_ because I need to set up
> something before carying on with the transform, but then it proved not
> enough.  Actually I have a stack in which I save the state of what I
> am doing, a state that influences what goes after.  Nevertheless, I
> find that is not enough at least in two cases.

Yes, you may be right; I thought that it would be enough always, but I
may be wrong there. I'll have to give that some more thought.

> For example, in an if, I have to provide the same stack for the expr,
> the iftrue and the iffalse parts.  Right now, I have the problem that
> in the iffalse part I get the stack as set by the iftrue part so I
> think I would have to redefine the children_if method to make a copy
> of the stack on entry and give each branch the same node.  I could pop
> the stack in the post_ method at each step, but I also need to check
> that the stack ends in the same state on each branch even if it gets
> to different depths.  Same with switches.

Yeah, sounds like you will need children_xxx. Fortunately, they are now
much easier to define than pre-0.1.6.

> I'll try that out, though I will also break it into two passes, one to
> analyze what has to be done and make sure everything is consistent,
> leaving information along the tree in the 'attrs' map and then doing
> the actual transformations in the second pass.  Perhaps later I might
> find that I can do the analyzis on the pre_methods and then the
> transformation on the post_methods, but I bumped into a couple of
> things that I can't get a clear image of when trying to do everything
> at once.

Actually, I think it's generally a good idea to split things up into
an analysis phase (which can use tree_visitor, so that you have access
to generic methods) and a transform phase (using tree_transform). It
might make the code much clearer.

Edsko