On Tue, Oct 26, 2021 at 3:14 AM Marc Nieper-Wißkirchen <xxxxxx@gmail.com> wrote:

I think the current generator proposal is fine for situations where the eof object is naturally a value that cannot appear, and this means reading and writing of external representations of Scheme objects (that do have such representations).

Among other things.  The eof object is fine for make-{iota,range}-generator and for {string,bytevector}->generator as well.

SRFI 121 and SRFI 158 are, however, advertised to be used in much greater generality. But when they are used to code general algorithms for sequences, the then implementation detail of using eof objects won't be hidden and the algorithms will fail on the most general sequence.

As long as that is documented (and I agree it needs an erratum for that), I don't see a problem.

For code that is supposed to handle general sequences, a protocol where the output of a generator is a SRFI 189 Maybe would help a lot to write clear and less error-prone code.

That's a possibility, yes.

It does, however, will create an object (the Maybe) that is just going to be destructed by the generator's consumer.

Indeed.

Thus, I find a protocol where the generator-like procedure receives two "continuation procedures" much more natural (especially for a language having proper tail calls). Some syntax could abstract over both cases:

Please demonstrate how gmap would be written and how to set up a gmap tree with a set of map and reduce steps.