I've thought some more about how to support slicing in the case of take(someInfiniteRange, someNumber) and I think it would be a good idea to require infinite random-access ranges to support an advance() function.  This would basically be like slicing, but only change the beginning of the range, not the end (since there is no end of an infinite range).  Calling infiniteRange.advance(N) would be equivalent to calling infiniteRange.popFront() N times, except that advance() would have O(1) time complexity.  Sound good?  Any alternative suggestions?

On Sun, Aug 15, 2010 at 4:29 AM, David Simcha <dsimcha at gmail.com> wrote:
> I've thought some more about how to support slicing in the case of
> take(someInfiniteRange, someNumber) and I think it would be a good idea to
> require infinite random-access ranges to support an advance() function.
> ?This would basically be like slicing, but only change the beginning of the
> range, not the end (since there is no end of an infinite range). ?Calling
> infiniteRange.advance(N) would be equivalent to calling
> infiniteRange.popFront() N times, except that advance() would have O(1) time
> complexity. ?Sound good? ?Any alternative suggestions?
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>

O(1) advance() is not always possible (not that it means your
suggestion is bad).

Scratch that, I missed the "random access" part.

We have popFrontN already in std.range. It's specialized for ranges with slicing.

The problem is that the '$' operator is not implemented yet. When it will, infinite ranges that want to offer slicing may define it to return a particular symbolic value. Then you can use r[5 .. $] to skip the first 5 elements of the range.


Andrei

On 08/14/2010 07:29 PM, David Simcha wrote:
> I've thought some more about how to support slicing in the case of
> take(someInfiniteRange, someNumber) and I think it would be a good idea
> to require infinite random-access ranges to support an advance()
> function. This would basically be like slicing, but only change the
> beginning of the range, not the end (since there is no end of an
> infinite range). Calling infiniteRange.advance(N) would be equivalent to
> calling infiniteRange.popFront() N times, except that advance() would
> have O(1) time complexity. Sound good? Any alternative suggestions?
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

On 9/5/10 23:36 CDT, David Simcha wrote:
> One more thing:  Are we going to make infinite random access ranges implement [num..$] slicing as part of their definition? IMHO we should.

Only those that can implement it in O(log n).

Andrei