Re: cool generators insight

From: David Abrahams (gclbb-jamboost_at_[hidden])
Date: 2003-06-05 10:07:03

Vladimir Prus <ghost_at_[hidden]> writes:

> David Abrahams wrote:
>> Vladimir Prus <ghost_at_[hidden]> writes:
>> > Hmm... the first one should be converted to NM_ASM. The generator should
>> > produce targets in fixed order, I believe.
>>
>> A generator with signature A -> B B produces two Bs at the same
>> time. Am I missing something?
>
> True. However, the first CPP returned is always the one which must be 
> processed further.

???
Seems totally arbitrary.
What's the basis for that rule?
What if both need to be processed further?

>> What element of the system other than your parenthesized note (which
>> I don't believe can be captured in code) indicates that the first one
>> should be converted instead of the 2nd one?
>
> In the current system you can describe it by creating a generator STATIC_DATA 
> <- ECPP, which will 
> 1. Create CPP from ECPP by recursive call to 'generators.construct'.
> 2. Take a first CPP and convert it to NM_ASM by another call to 
> 'generators.construct'.
> 3. Convert NM_ASM to STATIC_DATA
> 4. Return STATIC_DATA and the second CPP
>
> If you take a look at Jamfile for part of this example, still at
> http://zigzag.cs.msu.su:7813/Jamfile.v2
> you'll notice similiar approach.

As far as I can tell, if you have a system which solves this
particular problem in the way you want, it's just because the system
has been tuned for this particular problem. I don't think it
generalizes well.

> It's not automatic, but user can be asked to do such things for
> complex transformations. And it must be able to do that.

Why not just declare intermediate main targets? It seems so much
simpler and more-predictable.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com