Re: [boost] [range/iterators/algorithms/phoenix/bind...] Coordinated Approach

From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2008-07-01 22:45:13

On Tue, Jul 1, 2008 at 8:28 PM, Giovanni Piero Deretta
<gpderetta_at_[hidden]> wrote:
> On Tue, Jul 1, 2008 at 12:50 PM, Dean Michael Berris
> <mikhailberis_at_[hidden]> wrote:
>>
>> Isn't the whole point of creating an expression template
>> based-approach to create these (maybe using proto I guess) and allow:
>>
>> 1. The same placeholders used in Phoenix+Proto to be used in the pipe
>> syntax in range_ex (or an imaginary new RangeEx implementation).
>> 2. Allow for efficient (i.e., compiler optimized/assisted)
>> implementations of the composition of these new
>> views/ranges/iterators.
>>
>
> Of course. My point is that you need very few beyond what is available
> in Phoenix. Just the ability to have
> a placeholder which doesn't make the whole expression lazy ( i.e.
> foo(_) should be the same as unlambda(bind(foo, _1)) ).
>

When you say the whole expression lazy, do you mean even the for_each?

Why don't you want the range generation functions (or the pipe syntax)
return a lazy range? Perhaps something that only gets activated when
begin(range) and end(range) are invoked?

>> ?
>>
>> Although I do like how this looks granted that you are using C++0x's
>> auto -- in today's C++, the reason I used the STL was to avoid having
>> to compute the actual type produced by the pipe syntax.
>
> You need to know the result type of the reducer even in your example,
> so it is not specific to the 'sugared' syntax :)
>

for_each ( range(source) | take(10) | map(mapper()), cout << arg1 <<
endl ); // with Phoenix

Assuming that there's a boost::for_each(range<T>, F) -- I don't think
I need to know the result type of the reducer in that example. Am I
missing something?

>> Maybe this is
>> why Dave is asking for a better BOOST_TYPEOF. ;-)
>
> Well, as long as the result type of the final fold has been
> registered, it should work out of the box.
>

Of course, registered manually you mean? Or do you rely on
compiler-specific 'typeof'?

>>
>> Okay, but shouldn't this composition with transform_iterator be done
>> with something that 'comes out of the box'?
>
> It is ok to provide a zip+transform in a single function, but it is
> not a primitive. Let's call it zip_with, its result type should be
> transformed_range<zipped_range<RangeTuple> , Mapper>, we do not need
> an explicit zippedWith_range (and in fact it would make deforestation
> harder).
>

Shouldn't the deforestation already have happened in the zipping and
application of the function to yield another tuple?

-- 
Dean Michael C. Berris
Software Engineer, Friendster, Inc.