Caching in computing ranges

[Tomek Sowiński]

Pelle napisał:

> On 10/09/2010 09:38 PM, Tomek Sowiński wrote:
>> I've been having fun with ranges lately. While nesting computing ranges I
>> noticed only the outermost range's cache is necessary; there's no way of
>> accessing front() of ranges deeper in the expression twice because they
>> are sealed by the outermost range. Example:
>>
>> map!"a._0 + a._1"(    // caches, front() may be called twice
>>     zip(    // oh, trumpet: front() is called only to compute outer map's
>>     cache
>>         map!"a*a"([2, 4, 5, 6]),    // oh, trumpet
>>         take(sequence!"a._0 + n * a._1"(1, 2), 4)    // oh, trumpet
>>     )
>> );
>>
>> Eliminating superfluous caches, among other benefits, allows inlining the
>> (usually cheap) front()s. One way to do it is to parametrize computing
>> ranges with an enum Cached.(yes|no). What you think?
>>
> 
> How about never having caches and if you need them, you can get a
> cached(map(..etc..))?

That's an excellent idea.

> I do not understand where the notion that ranges should have caches come
> from. It destroys the possibility for using const and complicates the
> writing of them.

Plus, computations are done in popFront(). Then skippers like Stride compute many values 
in vain.

-- 
Tomek