Sketch specification/documentation draft:
<https://gitlab.com/dpk/presrfis/-/blob/master/iterators/cursors.md>

Equally sketchy implementation (avert your eyes if you have a fear of untested premature optimization):
<https://gitlab.com/dpk/presrfis/-/blob/master/iterators/cursors.scm>

Iteration cursors can be advanced (a) pure-functionally, by allocating a new one, or (b) imperatively, by mutating the old one. Which one can be chosen by the consumer, provided the producer doesn’t mutate any external state. The idioms for both creating and moving/advancing cursors are familiar from named let and using car/cdr to move down a Scheme list, respectively. Sequences can be finite or infinite and can contain any Scheme datum.

A potential problem with this design: no provisions for sequences where each place is occupied by multiple values. Ruby’s ‘enumeration’ protocol supports this and uses it to implement combinators that e.g. attach a numeric index to each step of the iteration; Python's iterators sort-of support this, by using a tuple.

A complete SRFI library for this would want to provide cursor-based analogues of most of the generator-* and g* procedures. This is just an initial proof-of-concept.

Thoughts welcome.

Daphne