Yes, your reasoning makes sense, everything looks good. Sorry for not
replying sooner.

- Adam

On 6/4/20 4:00 AM, Marc Nieper-Wißkirchen wrote:
> Dear Adam,
>
> as Arthur has issued a last-call for SRFI 190, I would like to check
> with you because you haven't answered to this thread anymore.
>
> Of course, it is also fine if you are fine with my reasoning. :)
>
> Thanks,
>
> Marc
>
> (This email is private, so make sure to include the list in case you
> want to post to everyone.)
>
> Am Mo., 27. Apr. 2020 um 22:50 Uhr schrieb Adam Nelson <xxxxxx@nels.onl>:
>> Hi everyone! This is my first time using a Scheme mailing list, so apologies if I don't understand the etiquette or how to use the mailing list system yet.
>>
>> The current SRFI 190 implementation requires syntax parameters and syntax-case, and cannot be implemented as a library on top of pure R7RS-small.
>>
>> It occurs to me that there's a simple way to implement SRFI 190 in R7RS, with no dependencies beyond make-coroutine-generator from SRFI 158, by making yield an ordinary function that calls a parameter:
>>
>> (define local-yield
>>    (make-parameter
>>      (lambda (x)
>>        (error "yield: called outside of coroutine-generator" x))))
>>
>> (define (yield x)
>>    ((local-yield) x))
>>
>> (define-syntax coroutine-generator
>>    (syntax-rules ()
>>      ((_ . body)
>>        (make-coroutine-generator
>>          (lambda (coroutine-yield)
>>            (parameterize ((local-yield coroutine-yield)) . body))))))
>>
>> This has two properties that, depending on your point of view, are either bugs or features:
>>
>> yield is a function, not syntax
>> yield is bound dynamically, not lexically, so functions called by the coroutine-generator but defined outside of it can still yield
>>
>> In my opinion, dynamically binding yield could be a feature. It makes it easier to decompose coroutines into reusable functions, and it adds new functionality to this SRFI beyond syntax sugar.
>>
>> Opinions?