On 10/9/10 14:38 CDT, 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?

I think it's a good idea. In fact let's eliminate caching altogether; it does not happen for the random access operator anyway and I think it's fair to simply evaluate the function whenever an element is accessed. Whaddaya think?

Andrei

Reply via email to