std.range.cacheFront proposal&working code: wraps a range to enforce front is called only once

[Timothee Cour]

On Thu, Oct 24, 2013 at 12:50 PM, Jonathan M Davis <jmdavisProg at gmx.com>wrote:

> On Thursday, October 24, 2013 12:14:27 Timothee Cour wrote:
> > so far you've emphasized on the fact popFront should take care of all
> side
> > effects and front should be logically pure and fast to compute, but you
> > haven't suggested any alternative for what I'm trying to achieve.
> >
> > In what I propose it's generic (works in all cases) and simple (just add
> > ".cacheFront" after a lambda with side effect):
> >
> > auto test(T)(T elements) if(isInputRange!T){
> > return elements
> > .map!( (a) {preaction(a); auto b=transform(a); postaction(a,b); return
> b;})
> > .cacheFront
> > .filter!foo; //or joiner or....
> > }
> >
> > So, how do you achieve the above without using cacheFront, without
> creating
> > a _custom_ range or writing a lot of code ?
> > I don't see how using foreach is a good idea (ForEachType!=ElementType,
> it
> > doesn't reuse phobos functionality and doesn't play well with phobos
> range
> > functions)
>
> If you don't want to do this with foreach


foreach is not lazy, so not an option


> , then creating a custom range is exactly what you should be doing,


why make user reimplement the wheel each time with a custom range when a
generic solution (such as above, maybe could be improved) works ?


> and the logic for the pre and post operations should go in popFront.


how can a *pre*-operation go in popFront, which occurs *after* front
(without significant gymnastics) ?


> Having side effects in front is just begging for problems, and it's not at
> all what map is designed for. And honestly, if
> your popFront isn't pure as well, and the side effects that you're doing
> affect
> something outside of the range, then I would suggest that you not use
> ranges
> for what you're doing, because that violates their functional nature.


That's an arbitrary restriction. I've faced many situations where I could
use the full power of range based algorithms while not restricting myself
to purely functional code (necessary side effects). With proper care it can
be done. Again, no need to reimplement standard algorithms just because of
some impure lambdas.


> It has been proposed before that a function be added to Phobos which did an
> operation when iterating over an element, in which case that operation
> would
> go in popFront, and front would just return the wrapped front. That would
> probably get you what you want and be more generally applicable than
> cacheFront.
>

Are you referring to proposals for tap ? There were many proposed, so not
sure which one you're mentioning. Or something else?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20131024/468e8e17/attachment.html>