There’s a long thread about this, I think on github but I forget exactly where. I proposed a way to make Rest work in the way that you’re expecting, but that would break the ideal of statelessness for patterns, so then it was suggested to add a method to convert a pattern’s output to rests, e.g., pattern.rest – which, two issues, 1/ then rest(pattern) would work, but not Rest(pattern) and that would confuse people, and 2/ it can’t be a simple filter pattern because normally you wouldn’t embed a long stream of rests.
So it turns out not to be a simple issue to design.
That’s exactly the problem I hinted at: “it can’t be a simple filter pattern because normally you wouldn’t embed a long stream of rests.”
I did make a proposal at one point where Rest would automatically make a stream for its argument, and then, when it’s embedded in an output stream, it would dole out one value and return control back to the parent stream. This would have done what you expected in your initial example. That’s problematic in this case though:
// note: this isn't supported in SC currently!
// if you try to run it, you won't get a sensible result.
// this is just to illustrate a scenario where
// a seemingly intuitive Rest behavior becomes un-intuitive
p = Pseq([Pn(1, 3), Rest(Pseries(0, 0.25, inf))], inf);
q = p.asStream;
r = p.asStream;
Here, you would expect the q and r streams to be completely independent – but if Rest “auto-streamifies” internally, then there’s one Rest object = one stream, shared between the two parent streams.
There’s no good solution to this… which is why we never put in that behavior.