Treatment of big-E Expression objects in expression walkers (Feedback requested)

[carldlaird]

From comment on PR #272

"Further, in the walkers, sometimes named expressions are treated as leaf nodes and sometimes they are not. This is one of the big sources of confusion for the walkers, as there are operations where a reasonable user would sometimes want the Expression to be a leaf and sometimes for it to be an internal node. Two big examples of this are string generation and substitution."

I agree that there are times it is reasonable to treat the Expression objects one way and times it is reasonable to treat them another. Please post your design thoughts here.

Possible ideas:

• extend the walkers to include flags that can be set by derived classes to determine behavior
• others?

[whart222]

IMHO, these customizations are not necessary. There currently are two methods that determine the behavior of the walkers, and this control is determined within those methods. Thus, there's nothing in the normal walker logic that is specific to the object type.

An exception are the replacement walkers, where by design I've hard-coded a lot of decisions into the walker itself. But those decisions merely control how new expression nodes are created after modifying children. Again, the two methods control whether the walker terminates at a node.

[carldlaird]

OK. It is exactly this last point where the immediate questions lie.

But those decisions merely control how new expression nodes are created after modifying children.

I can see cases where people would want to perform a substitution and have the big-E Expression object stick, and I can see cases where people would want the big-E expression object to be removed after the substitution. So it is exactly the issue you bring up that may need to be addressed.

[mrmundt]

In an effort to clean up old issues, we are moving some design discussions to our Archived Design Discussions wiki.

[jsiirola]

Note that this appeared to be a duplicate of #416