Simpler implementation with R7RS parameters? Adam Nelson (27 Apr 2020 20:50 UTC)
(missing)
Re: Simpler implementation with R7RS parameters? Adam Nelson (04 Jun 2020 18:13 UTC)
Re: Simpler implementation with R7RS parameters? Marc Nieper-Wißkirchen (04 Jun 2020 18:16 UTC)
Re: Simpler implementation with R7RS parameters? Shiro Kawai (05 Jun 2020 01:05 UTC)
Re: Simpler implementation with R7RS parameters? Marc Nieper-Wißkirchen (05 Jun 2020 06:16 UTC)
Re: Simpler implementation with R7RS parameters? Shiro Kawai (05 Jun 2020 07:07 UTC)
Re: Simpler implementation with R7RS parameters? Marc Nieper-Wißkirchen (05 Jun 2020 07:37 UTC)
Re: Simpler implementation with R7RS parameters? Shiro Kawai (05 Jun 2020 09:14 UTC)
Re: Simpler implementation with R7RS parameters? Marc Nieper-Wißkirchen (28 Apr 2020 06:27 UTC)
Re: Simpler implementation with R7RS parameters? Marc Nieper-Wißkirchen (05 May 2020 14:56 UTC)

Re: Simpler implementation with R7RS parameters? Marc Nieper-Wißkirchen 28 Apr 2020 06:27 UTC

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.

Thank you a lot for chiming in!

> 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's true that SRFI 190 requires syntax parameters. It doesn't really
need syntax-case, though; what it needs are identifier macros, which,
in principle, can be supported by any er-macro-transformer or
syntax-rules macro system. (In fact, without identifier macros, syntax
parameters lose much of their power.)

> 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:

It hasn't been my goal to make this SRFI implementable in terms of
R7RS-small (although your implementation could be used as a poor man's
implementation in Schemes that miss the needed features). The point is
more or less the other way round: A Scheme system could provide SRFI
190 using an implementation-specific environment even though it might
not possess general syntax parameters or identifier macros. This gives
more added value to the user than shipping SRFIs that can easily be
implemented on top of R7RS-small.

[...]

> This has two properties that, depending on your point of view, are either bugs or features:
>
> yield is a function, not syntax

That's fine. But notice that in my implementation `yield' also behaves
like a function, which you can pass around. So here is not much of a
difference.

> 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.

I see it as a bug. Scheme is lexically scoped and not dynamically
scoped. If `yield' is needed in helper functions, you can simply pass
it as an explicit parameter. If you really want dynamic binding, you
can easily introduce a parameter in your code.

Lexical scoping helps encapsulation while `yield' as a dynamic
variable could be accessed by whatever unrelated function once it has
been set by a coroutine generator somewhere in the call stack.
Furthermore, dynamic binding does not work well with closures (which
do not close over the dynamic environment).

There is a third difference between the two approaches: The approach
with syntax parameters is as efficient as using
`make-coroutine-generator' directly; the approach with parameters
involves (in most Schemes) dynamic-bind and would need *a lot of help*
from the optimizer to achieve the efficiency of the bare-metal
approach.

[...]

Marc