A proposed solution to the iteration problem Daphne Preston-Kendal (01 Dec 2021 21:00 UTC)
Re: A proposed solution to the iteration problem Arthur A. Gleckler (01 Dec 2021 21:54 UTC)
Re: A proposed solution to the iteration problem Marc Nieper-Wißkirchen (02 Dec 2021 12:42 UTC)
Re: A proposed solution to the iteration problem Marc Nieper-Wißkirchen (03 Dec 2021 07:21 UTC)
Re: A proposed solution to the iteration problem Daphne Preston-Kendal (03 Dec 2021 09:16 UTC)
Re: A proposed solution to the iteration problem Marc Nieper-Wißkirchen (03 Dec 2021 12:50 UTC)
Re: A proposed solution to the iteration problem Marc Nieper-Wißkirchen (03 Dec 2021 14:56 UTC)
Re: A proposed solution to the iteration problem Daphne Preston-Kendal (04 Dec 2021 11:09 UTC)
Re: A proposed solution to the iteration problem Marc Nieper-Wißkirchen (04 Dec 2021 13:54 UTC)

A proposed solution to the iteration problem Daphne Preston-Kendal 01 Dec 2021 21:00 UTC

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