Re: [Boost-users] [boost-users][[proto] : Seeking advice on a DSL

On 3/18/2010 1:47 PM, Manjunath Kudlur wrote:

...

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.

I don't see how. When you create your "program", the data are not yet available. They are only supplied later when you are ready to execute your "program". I must be misunderstanding what you're suggesting.

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().

No, you need to define operator[] for the expression returned by Program(). You need operator() on whatever is 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.

They shouln't, unless your generator is doing something extra.

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"?

No comments, other than that it feels vaguely wrong to me. I was intrigued enough by this problem to have a go at implementing my suggestion above. It seems to work (see attached). This is a rough mock-up and needs much work. In particular, see the TODO for the overloaded operator() in program_expr. But on the whole, this seems workable. Note, you'll need to use the latest version of Proto from trunk. I had to fix two bugs to get this to work. :-( -- Eric Niebler BoostPro Computing http://www.boostpro.com