On 25 Oct 2021, at 12:37, Marc Nieper-Wißkirchen <xxxxxx@gmail.com> wrote:

>> Unfortunately, we probably can’t take (scheme generator) out of R7RS and replace it completely by something else, as it was voted in in the Red edition and thus far, John seems resistant to incompatible changes between editions.
>
> I think that not allowing incompatible changes to earlier editions would be a mistake. So *if* everyone (or a majority) agrees that the generator protocol should be replaced, it should actually be replaceable.

Well, John would have to decide. It’s true that while we have an obligation to compatibility with R7RS small, we don’t have such an obligation in relation to previous, pre-final ‘editions’ of R7RS Large.

>> list->iterator requires a new closure to be created at every step, and that doesn’t seem surmountable, even by changing the design.
>
> You need to create something because of persistence. An SSC can reuse the created closure if the old iterator state is immediately thrown away.

Are there SSCs that can do this in the general case?

>> So is there a use case for functional iterators?
>
> That's the wrong question and cause all my alarm bells to ring, so to speak. <snip>
>
> So an imperative generator protocol (with the eof-flaw cured in some way) has its niche (namely when a Sufficiently Smart Compiler is not available), but the protocol that gets the spotlight (and should be used unless the performance is proveably insufficient) should be a functional one.

Perhaps I should then have asked: is there a use case for functional iterators making them notably distinct from SRFI 41 streams? We already have those; they’re a tested design with a heritage in SICP; they don’t have the flaws of generators, but they’re purely functional, also requiring consing at each step of creating the stream. (Your proposal would admittedly require *less* consing — just one procedure, as opposed to two procedures and a pair.)

>> Evidently the voters on the Red Edition ballot were okay with an iteration pattern which doesn’t allow the eof-object to occur in sequences.
>
> I am not sure whether it was even discussed or whether the voters were aware that the claim in SRFI 158 that generators can be used as "glue" between sequence types is not correct.

True. It comes back to your objection about the voting process.

Daphne