range.save

[Joseph Rushton Wakeling via Digitalmars-d]

On Friday, 27 November 2015 at 12:16:34 UTC, Jonathan M Davis 
wrote:
> Well, if you're dealing with a pseudo-random generator with a 
> specific seed, I'm not sure that it's okay, though obviously 
> for a fully random number generator, it wouldn't matter.

I think the distinction here is artificial.  If `range` is a 
random number generator, then `take` has no right to expect its 
output to be deterministic or consistent in any way.

When we come to input ranges in general, that's surely a factor 
we need to take into account.  Can the InputRange actually be 
relied on as a deterministic iteration, but one where we can't 
save our state?  Or should it be treated as simply a source of 
data, about which one can make no assumptions regarding its 
consistency?

I think answering that question -- and maybe distinguishing the 
two cases if possible -- feeds into how to address the subsequent 
problems you describe.

> Possibly, but because almost everything in Haskell is both 
> functional and lazy, you don't really get the problem of 
> popFront being called after the call to take.

I'm not sure that's really true.  I'm reasonably sure that I can 
(given some source of IO) do something like (pseudo-code because 
my Haskell is rusty),

     do
         lazyData = 
something_that_lazily_reads_5_entries_from_the_IO_entity
         read_some_data_from_IO
         read_some_data_from_IO
         do_something_with_lazyData

If the source of IO is the standard random number generator of 
Haskell, for example, it'll behave like the input range/popFront 
example.