On 8/11/22 4:15 AM, Marc Nieper-Wißkirchen wrote:
> ---- *External Email*: Use caution with attachments, links, or sharing
> data ----
>
>
> (CC to SRFI 231 mailing list because the issue came up there most recently.)
>
> As `generator-fold` is the universal adapter from the impure, imperative
> world of generators to the pure functional subset of Scheme, I think it
> is important that it still works correctly in the presence of call/cc
> (and outside mutation).
>
> The most naive correct (in the sense of the above) implementation of
> generator-fold would therefore have to be
>
> (define generator-fold
>    (lambda (proc . gen*)
>      (apply fold proc (map generator->list gen*))))
>
> A more space-efficient implementation (at least, when multiple threads
> are not involved) would be
>
> (define generator-fold
>    (lambda (proc . gen*)
>      (apply lseq-fold proc (map generator->lseq gen*))))
>
> For that, lseq-fold with call/cc-correct semantics should be added to
> SRFI 127.
>
> The most efficient implementation would need a way to detect whether a
> continuation is captured in the dynamic extent of `proc`.  (There should
> probably be a SRFI for that because this cannot be done portably without
> redefining call/cc.)  As long as no continuation is captured, the naive
> implementation would be used.
>

(Replying only to the SRFI 231 mail list.)

I don't understand whether this email implies that I should make further
changes to SRFI 231's specification or implementation (although I
suspect it does not).

For the record, I believe that SRFI 231's array-foldl and array-foldr
now both work "correctly in the presence of call/cc".

Brad