Re: [boost] Formal Review: Boost.RangeEx

Subject: Re: [boost] Formal Review: Boost.RangeEx
From: Giovanni Piero Deretta (gpderetta_at_[hidden])
Date: 2009-02-25 13:58:05

On Wed, Feb 25, 2009 at 7:39 PM, Thorsten Ottosen
<thorsten.ottosen_at_[hidden]> wrote:
> Giovanni Piero Deretta skrev:
>>
>> On Wed, Feb 25, 2009 at 7:04 PM, Thorsten Ottosen
>> <thorsten.ottosen_at_[hidden]> wrote:
>
>>> What about something like
>>>
>>>  total = r | filter(f) | map(m) -> accumulate(zero, a);
>>>
>>
>> how would you make this work (leaving the framework extensible to new
>> algorithm)? Maybe you meant ->*.
>>
>>> or
>>>
>>>  total = r | filter(f) | map(m) >> accumulate(zero, a);
>>>
>>
>> I sort of like the >> syntax (btw, I think that there are functional
>> languages that use the same syntax for function chaining), but I do
>> not see the necessity of distinguishing between '|' and '>>'. Just use
>> one.
>
> Well, since there is a semantical difference, and a large one, I'm
> leaning towards that we should use two operators.
>

Still not convinced. You might have a case if the last algorithm in
the above chain were a mutating one, like sort, but I used accumulate
which is a pure function, like map and filter. I do not see much of a
difference. Similarly for_each, which while not a pure fuction, it is
often used in a way that doesn't mutate its arguments.

So no, I do not think that there is a large difference between
adaptors and algorithms. I only see the usual difference between
mutating and non mutating algorithms.

> Especially is we will have both adaptor::transform and transform as an
> algorithm.
>

Again, I think that the mutating and not mutating algorithm should
have different names.

>>> ?
>>>
>>> The is a problem when we just want to apply several algorithms:
>>>
>>>  boost::erase( cont, boost::unique( boost::sort(cont) ) );
>>>
>>
>> I woudn't put many inplace algorithm in the same expression nor
>> encourage users to do it. The unique->erase idiom is common, on the
>> other hand sort has little reason being in that expression.
>
> Unique won't work properly if you don'e have a sorted sequence, AFAIR
>

IIRC there is no requirement for the range to be sorted: unique will
just remove all but one elements on a run of equivalent elements. But
I agree that's not how it is often used.

Anyways, probably that's more of a case for encapsulating the
sort/unique/erase sequence in a single  algorithm.

-- 
gpd