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
