I feel like isInfinite is useless for typical cases... the only "infinite" (perhaps I should call it "unbounded" instead?) range I've ever realistically come across is a stream, like console input or a network stream.

Of course, isInfinite doesn't make any sense for any type of wrapper around console input -- is it true or false?
You can't tell, because it depends on whether the input is redirected.
If the console input was redirected, then it would be finite, with a certain length (the length of the file).
If not, then it would be infinite (er, unbounded).

So IMHO, we should deprecate isInfinite entirely, and instead rely on length being size_t.max.

Not only would it make more sense, but it would make it possible to create a random-access wrapper around an input range (like console input), which lazily fetches its data.
Then you can work with console input like a regular string!

On Monday, 25 June 2012 at 17:26:23 UTC, Mehrdad wrote:
> I feel like isInfinite is useless for typical cases... the only "infinite" (perhaps I should call it "unbounded" instead?) range I've ever realistically come across is a stream, like console input or a network stream.
>
> Of course, isInfinite doesn't make any sense for any type of wrapper around console input -- is it true or false?
> You can't tell, because it depends on whether the input is redirected.
> If the console input was redirected, then it would be finite, with a certain length (the length of the file).
> If not, then it would be infinite (er, unbounded).
>
> So IMHO, we should deprecate isInfinite entirely, and instead rely on length being size_t.max.
>
> Not only would it make more sense, but it would make it possible to create a random-access wrapper around an input range (like console input), which lazily fetches its data.
> Then you can work with console input like a regular string!

This also prompts another issue:
The length of a range should be a long, not size_t.

Otherwise there's no way we could possibly replace streams with ranges. 32-bit systems have LOTS of common streams that are over 2^32 bytes (e.g. DVD images, partition images, large movies, etc.).

On Mon, 25 Jun 2012 13:26:22 -0400, Mehrdad <wfunction@hotmail.com> wrote:

> I feel like isInfinite is useless for typical cases... the only "infinite" (perhaps I should call it "unbounded" instead?) range I've ever realistically come across is a stream, like console input or a network stream.
>
> Of course, isInfinite doesn't make any sense for any type of wrapper around console input -- is it true or false?
> You can't tell, because it depends on whether the input is redirected.
> If the console input was redirected, then it would be finite, with a certain length (the length of the file).
> If not, then it would be infinite (er, unbounded).
>
> So IMHO, we should deprecate isInfinite entirely, and instead rely on length being size_t.max.
>
> Not only would it make more sense, but it would make it possible to create a random-access wrapper around an input range (like console input), which lazily fetches its data.
> Then you can work with console input like a regular string!

I think you misunderstand an infinite range.  There are plenty of truly infinite ranges available.

An example infinite range:

struct Infinite
{
   int x;
   @property int front() { return x;}
   void popFront() {}
   enum empty = false;
}

length has nothing to do with infinite ranges.  In fact, infinite ranges should have no length member.

-Steve

On 06/25/2012 07:26 PM, Mehrdad wrote:
> I feel like isInfinite is useless for typical cases... the only
> "infinite" (perhaps I should call it "unbounded" instead?) range I've
> ever realistically come across  is a stream, like console input or a
> network stream.
>

Console input or network streams can be terminated.

> Of course, isInfinite doesn't make any sense for any type of wrapper
> around console input -- is it true or false?
> You can't tell, because it depends on whether the input is redirected.
> If the console input was redirected, then it would be finite, with a
> certain length (the length of the file).
> If not, then it would be infinite (er, unbounded).
>

Infinite lazy ranges are an useful abstraction. You could read up on
Haskell. Lists in Haskell programs are often infinite.


> So IMHO, we should deprecate isInfinite entirely, and instead rely on
> length being size_t.max.
>

Infinite ranges do not have a length.

> Not only would it make more sense, but it would make it possible to
> create a random-access wrapper around an input range (like console
> input), which lazily fetches its data.
> Then you can work with console input like a regular string!

An infinite range can be buffered lazily just fine.

On Monday, 25 June 2012 at 17:38:55 UTC, Steven Schveighoffer wrote:
>
> I think you misunderstand an infinite range.  There are plenty of truly infinite ranges available.
>
> An example infinite range:
>
> struct Infinite
> {
>    int x;
>    @property int front() { return x;}
>    void popFront() {}
>    enum empty = false;
> }
>
> length has nothing to do with infinite ranges.  In fact, infinite ranges should have no length member.
>
> -Steve

Oh, I see. So they're truly infinite, not just unbounded.

In that case, how do you make a random-access wrapper around an input range?
(i.e. What do you use for 'length'?)

On Monday, 25 June 2012 at 17:28:27 UTC, Mehrdad wrote:
> On Monday, 25 June 2012 at 17:26:23 UTC, Mehrdad wrote:
>> I feel like isInfinite is useless for typical cases... the only "infinite" (perhaps I should call it "unbounded" instead?) range I've ever realistically come across is a stream, like console input or a network stream.
>>
>> Of course, isInfinite doesn't make any sense for any type of wrapper around console input -- is it true or false?
>> You can't tell, because it depends on whether the input is redirected.
>> If the console input was redirected, then it would be finite, with a certain length (the length of the file).
>> If not, then it would be infinite (er, unbounded).
>>
>> So IMHO, we should deprecate isInfinite entirely, and instead rely on length being size_t.max.
>>
>> Not only would it make more sense, but it would make it possible to create a random-access wrapper around an input range (like console input), which lazily fetches its data.
>> Then you can work with console input like a regular string!
>
> This also prompts another issue:
> The length of a range should be a long, not size_t.
>
> Otherwise there's no way we could possibly replace streams with ranges. 32-bit systems have LOTS of common streams that are over 2^32 bytes (e.g. DVD images, partition images, large movies, etc.).

Moved the other part to a separate thread:
http://forum.dlang.org/thread/wgulnffhhkorfvtzbnqb@forum.dlang.org#post-wgulnffhhkorfvtzbnqb:40forum.dlang.org

On Monday, June 25, 2012 19:43:00 Mehrdad wrote:
> On Monday, 25 June 2012 at 17:38:55 UTC, Steven Schveighoffer
> 
> wrote:
> > I think you misunderstand an infinite range. There are plenty of truly infinite ranges available.
> > 
> > An example infinite range:
> > 
> > struct Infinite
> > {
> > 
> > int x;
> > @property int front() { return x;}
> > void popFront() {}
> > enum empty = false;
> > 
> > }
> > 
> > length has nothing to do with infinite ranges. In fact, infinite ranges should have no length member.
> > 
> > -Steve
> 
> Oh, I see. So they're truly infinite, not just unbounded.
> 
> In that case, how do you make a random-access wrapper around an
> input range?
> (i.e. What do you use for 'length'?)

Input ranges cannot be random access. Iterating over them consumes them, and you have no way of knowing their length other then iterating over them and counting (which would consume them), so they have no length property. If you want an input range to be treated as a forward range or random access range, you're going to need to copy it into something first.

- Jonathan M Davis

On Monday, 25 June 2012 at 17:43:01 UTC, Mehrdad wrote:
> In that case, how do you make a random-access wrapper around an input range?

You don't. If you could, they wouldn't be an input range.

On Monday, 25 June 2012 at 18:29:45 UTC, Bernard Helyer wrote:
> On Monday, 25 June 2012 at 17:43:01 UTC, Mehrdad wrote:
>> In that case, how do you make a random-access wrapper around an input range?
>
> You don't. If you could, they wouldn't be an input range.


Wait, what?

I don't see why you _shouldn't_ be able to create a random-access wrapper that lazily reads as much data as it needs to, in order to satisfy a random read.

i.e. I see no obstacle, at least conceptually, other than the fact you're saying you can't do it.

On Tuesday, June 26, 2012 00:46:40 Mehrdad wrote:
> On Monday, 25 June 2012 at 18:29:45 UTC, Bernard Helyer wrote:
> > On Monday, 25 June 2012 at 17:43:01 UTC, Mehrdad wrote:
> >> In that case, how do you make a random-access wrapper around an input range?
> > 
> > You don't. If you could, they wouldn't be an input range.
> 
> Wait, what?
> 
> I don't see why you _shouldn't_ be able to create a random-access wrapper that lazily reads as much data as it needs to, in order to satisfy a random read.
> 
> i.e. I see no obstacle, at least conceptually, other than the fact you're saying you can't do it.

You can't do it as a proper random-access range. To do that, it would have to be a forward range, and if it's not a forward range already, then presumably, there's a reason why it can't be. You could easily tell it to give you the nth element, but that would require consuming all of the preceding elements to get to it. You could store those elements internally as you iterate over them, but normally, they'd be gone, meaning that skipping to the nth element would mean losing all of the preceding elements.

Regardless, unless you can find a way to define a save function which will return a copy of the range and be able to iterate over both of them separately and get exactly the same elements, then you can't have anything more than an input range as far as how the various ranges are defined goes. If you can somehow figure out how to do that via buffering, then you could make it a forward range as well as whatever other range types you could define the functions for, but you'd have to figure out a way to define save.

- Jonathan M Davis