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

Subject: Re: [Boost-users] [boost-users][[proto] : Seeking advice on a DSL
From: Eric Niebler (eric_at_[hidden])
Date: 2010-03-18 10:48:57

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<void*,int>  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