Am Do., 28. Okt. 2021 um 02:13 Uhr schrieb John Cowan <xxxxxx@ccil.org>:

On Mon, Oct 25, 2021 at 2:31 AM Daphne Preston-Kendal <xxxxxx@nonceword.org> wrote:

I proposed a solution to the first problem: generators become one-argument procedures instead of thunks, and return their single argument, instead of the eof-object, when exhausted.

I don't see that that helps much: a generator still can't return all the objects in the Scheme universe, so converting from lists to generators is still (technically) impossible. In addition, generator operations become much more complicated: gmap has to be told which end objects to pass to each of its generator arguments, since only the top-level caller knows what objects each argument cannot return as a normal value.

I think the idea is that the consumer of a generator creates a sentinel object that is guaranteed to be not `eq?' to any existing object.

All the procedures in an implementation of SRFI 158 could share the same sentinel as long as they make sure that it cannot leak outside the implementation.

Marc Nieper-Wißkirchen proposed a completely new API of functional iterators as two-argument procedures: (iterator next end), where next is a two-argument procedure receiving a new iterator plus the next item in the sequence, and end is a thunk called when the sequence is exhausted.

That's even more awkward to compose.

In what sense is this awkward to compose? I don't think so. In fact, writing down iterative algorithms with such a kind of iterator come very naturally. Maybe you can give an example where you think composability is problematic.