std.v2020.algorithm etc[ WAS: Is run.d going to be expand for runtime and the phobos library?]

Stanislav Blinov stanislav.blinov at gmail.com
Sun Jun 28 11:33:39 UTC 2020


On Sunday, 28 June 2020 at 10:42:14 UTC, Joseph Rushton Wakeling 
wrote:
> On Saturday, 27 June 2020 at 20:14:36 UTC, Stanislav Blinov 
> wrote:
>> Equality is very much part of the struct interface though. 
>> I'll restate. What about input.tail.empty == input.tail.empty? 
>> Or input.tail.front == input.tail.front? Or, speaking of 
>> ranges, a input.tail.equal(input.tail)?..
>
> Does it even make _sense_ to be able to call `tail` twice on 
> the same input range instance?

No, it does not, that's my point. "Don't do that" isn't the 
answer. "Can't do that" (statically disallowed, not present in 
the interface) is the answer.

>> If the explanation is "`tail() const` is impure, and calling 
>> it repeatedly with the same `this` produces different results,
>> even when `this` is immutable", "WTF???" would be quite a 
>> reasonable follow-up question.
>
> One of the problems with thinking about ranges -- and the 
> current range API reflects this -- is that it tends to start by 
> thinking about deterministic examples (e.g. arrays).

Arrays are random access ranges (which are also forward). They're 
not input ranges :)
The current range API incorrectly treats any range as at least an 
input range. If we are talking about making changes to range API 
- that is one of the changes that needs to be made.

> But while some input ranges may be deterministic in practice, 
> it is not possible to reasonably assume "same input, same 
> output" behaviour.  That's the whole _point_ of input ranges.

Yes, that is why an input range cannot be implementing `tail`. 
You cannot keep the original range *and* the tail. That's what 
forward ranges do.

> As an example: reading a stream of values from a crypto RNG, or 
> a "true random" source measured from some ongoing physical 
> process.
>
> A key thing to observe there is that, immutable or no, the 
> state of `this` doesn't give you complete information about 
> what comes next in the sequence, and indeed the result may also 
> depend on precisely _when_ the next element is requested (e.g. 
> if my input range is a "true random" noise source, I'm likely 
> to get a different value if I wait 0.1 sec to call it rather 
> than calling it right now, even if no one else has been using 
> that noise source).

> Conceptually that doesn't fit very well with the concept of 
> `tail`, but that's just a matter of a better name.

It isn't. It's a matter of semantics of the range. You can only 
consume or discard an input range. You can't fork it. Conversely, 
if you *can* fork a range - it's a forward range. Therefore, an 
input range cannot have a `tail` :)

> The real problem here isn't the indeterministic results, it's 
> the idea that the original `this` is usable after `tail` has 
> been called on it that is the problem.

We cannot, in the language, statically, express a "usability" of 
an lvalue.


More information about the Digitalmars-d mailing list