Am Sa., 29. Aug. 2020 um 02:44 Uhr schrieb John Cowan <xxxxxx@ccil.org>:
>
> Ranges aren't opaque like generators (or any procedure): they are vectors stored compactly.  You could write a macro to generate a procedure to emulate a vector using local variables, but you couldn't extract a subvector of it without chaining the procedures, which does not maintain O(1) reference and mutation in the long run.

That's all certainly true and this I understand. I would like to see
it in action where you need things like O(1) random access and the
ability to split ranges.

The example given in the rationale can already be readily solved with
generators, so if someone asks why ranges should also be added to the
language, it would be nice to have a simple compelling example that
can be solved with ranges but not with generators (or vectors or
lists) as efficiently.

PS You wrote "they are vectors stored compactly", which is a very nice
description, I think. As I read this, it came to my mind whether it
could make sense that ranges are not necessarily disjoint from
vectors. We already have literal vectors (where mutation is an error)
and ranges can fulfill the complete API of vectors. Of course, we
cannot make this polymorphism mandatory (without major changes to
every implementation), but we could make it optional by allowing
(range? x) => (vector? x).