More tricky range semantics

[Joseph Rushton Wakeling via Digitalmars-d]

On 16/01/15 07:38, H. S. Teoh via Digitalmars-d wrote:
> I've been wondering about that. Must ranges have an "underlying"
> container? Or are they allowed to be more abstract entities that
> basically function as generators, producing data on demand? (This
> distinction is also somewhat related to transient ranges, in that the
> difference between providing a "view" of some static underlying data vs.
> computing something on-the-fly in a buffer that gets reused, could serve
> as a deciding factor on how to deal with transient ranges.)

This is almost a surprising question for me, because I've taken it for granted 
for so long that one of the most powerful tools they offer is lazily-generated 
data that is not based on underlying storage.  The examples you cite (iota, 
recurrence) are good examples, RNGs are another.

> In this sense, an RNG could be thought of as a complex variant of
> recurrence(), except with a far more complicated generating expression
> than what one would normally use with recurrence(). If recurrence()
> qualifies as a range (and a forward range, no less), then an RNG ought
> to qualify too.

Yes, theoretically you can envision a pseudo-RNG as being defined by a state 
variable, and a pure function that transforms this into a new state variable. 
And then those individual states can be mapped to the individual variates in 
different ways, depending on the type of variate you want to generate.

The practical range implementation obfuscates this a bit (helpfully) by 
encapsulating the state (which in practice we update via mutation), and 
implementing a particular state-to-random-variate method in .front, resulting in 
the desired effect of a range whose elements are the individual random variates 
you care about.