Am Di., 28. Apr. 2020 um 08:27 Uhr schrieb Marc Nieper-Wißkirchen
<xxxxxx@nieper-wisskirchen.de>:

I should have also emphasized another point, which should end up in
the Rationale of this SRFI: While the sample implementation uses
syntax parameters and identifier macros, a specific implementation
that is being shipped by a particular Scheme system doesn't have to.
In fact, this is a reasonable thing for those systems, for which
MAKE-COROUTINE-GENERATOR from SRFI 121/SRFI 158 is slow because
CALL/CC is slow in these systems (unfortunately, such systems exist).
As COROUTINE-GENERATOR of SRFI 190 is just syntax and offers no more
than Python's generator functions (note that Python doesn't have
CALL/CC), those systems can translate it directly into fast code that
does not have to rely on first-class continuations. For this
translation to be easy (and no more difficult than that what CPython
has to do), it is very good thing that YIELD is lexically scoped (and
thus confined to the expanded body of the coroutine). Replacing YIELD
with a dynamically bound thing would make things worse.