
Tricky. I can imagine a scheme where, as you build the program expression, you walk the expression and keep a map
from parameters addresses (e.g. int_*) to monotonically increasing slot numbers; as you go, you can replace the parameters with their slot numbers. You end up with a program where each "a" is replaced with "slot(0)", each "b" with "slot(2)" and each "c" with "slot(3)" (where "slot" is some type that wraps a runtime int). Later, when evaluating the program, the parameters to the program are put in a std::vector, and the evaluator knows to evaluate "slot" terminals by indexing into the vector. Handling out parameters requires special handling, as would handling expressions where not all parameters have the same type. This is essentially the same as what you describe above, except the expensive mapping is done by the code the builds the program rather than the code that evaluates it.
Thanks, that does help. The other approach I was toying with was to hold the values "in situ", i.e., make int_ contain the datum. The biggest hurdle I am facing is the fact that proto copies around the objects held in proto::terminals, whenever they have to go through a generator. For example, I need to define operator(...) for the expression returned by Program(). For that, I put it in a domain, whose generator wraps the expression in a wrapper with operator(...), but during that process, the objects held at terminals get copied. So there is a new object created for each occurrence of a variable in the expression, which screws up the evaluator. Any comments on trying to hold the values "in situ"? Manjunath