improvements to symbolic package

[Stephen Siegel]

It is not clear what comprises the interface of the symbolic package. There is a sub-package called "IF", but not everything the outside user needs is in that sub-package (for example, SymExpression---and there is no SymExpressionIF). The interface and implementation need to be clearly separated.

Also, there needs to be a way to "decompose" a symbolic expression of array type. For example, we need to be able to tell that an expression is an "array write" expression and then get the sub-expressions for the original array, index, and new value. Or some other way needs to be provided to get the list of "assignments" made to an array. This functionality must be included in the interface to the symbolic package.

[Stephen Siegel]

I thought about this some more, and I think what is really needed and is something which is more general and also simpler.

Is it the case that every symbolic expression is a tree? The non-leaf nodes have an associated operation (like "+", or "subscript"), and then some number of children which are the arguments. The leaf nodes are either literals or symbolic constants.

If this is the case, then all that is needed is a "low level" interface that will support getting the operation and children from a symbolic expression, and creating a symbolic expression from an operation and a given list of children expressions. (There might even be methods that already do this, just not exported in the interface.)

If such methods are provided, then I can just walk through every symbolic expression in the state, and replace the old heap references with the new (when I do garbage collection). What do you think?

[ywei]

Yes, I think every symbolic expression has a tree structure. Are you suggesting that the symbolic expression interface provides methods such as getNumChildren(), getChild(index)? That could be done.

[Stephen Siegel]

Discussion moved to the Wiki in the "Things To Do" page.