Am Do., 24. Nov. 2022 um 23:06 Uhr schrieb John Cowan <xxxxxx@ccil.org>:
>
>
>
> On Wed, Nov 23, 2022 at 2:05 AM Marc Nieper-Wißkirchen <xxxxxx@gmail.com> wrote:
>
>> Consider, for example, SRFI 158.  Its make-coroutine-generator is
>> written with call/cc, which can cause a space leak.  With SRFI 226 at
>> hand, a better version (and a version compatible with continuation
>> barriers) of make-coroutine-generator is written with delimited
>> continuations.  Now, in those cases where it matters, a consumer
>> importing SRFI 158 should be able to make sure that the modern version
>> make-coroutine-generator is imported.
>
>
> This is not a good example, because SRFI 158 does not
> specify either that call/cc is used or that it is not used, so both
> implementations are valid.  If you want to be sure that there is
> no space leak, specify SRFI 226; if you want to be
> sure that your code will work on an R7RS-small system, specify
> SRFI 128.  Neither is intrinsically better than the other.

It was just an example, no more than that.  As the discussion about
unwind-protect showed, SRFI 158's make-coroutine-generator is quite
underspecified (what does "suspended" means in terms of the Scheme
semantics, for example).  It is not only about the question of space
leaks but also about the dynamic environment, for example, in which
the body of the procedure is evaluated, etc.  So under the assumption
(!) that there is agreement that the definition of
make-coroutine-generator should be amended, either a new SRFI could be
issued (extending SRFI 158) or SRFI 158 could be amended with a  PFN
that adds something to the specification of make-coroutine-generator.
My example was for the latter case:  in this case, some version of
(srfi 158) would be fine.

(With either specification of make-coroutine-generator, it makes sense
for an R7RS-small system.)