Am Sa., 1. Aug. 2020 um 05:49 Uhr schrieb John Cowan <xxxxxx@ccil.org>:
>
>
>
> On Fri, Jul 31, 2020 at 5:13 AM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:
>
>>
>> https://lists.gnu.org/archive/html/guile-devel/2019-07/msg00000.html.
>> Mark's arguments are sound, but they mean that an implementation may
>> be better with fewer SRFIs.
>
>
> In order to show that, you or Mark would have to show that Guile would be worse off with generators than with them.  He does not attempt to show this: he simply believes that because generators are for efficiency (and I regret making that remark in the SRFI), they need an efficient Guile-specific implementation.

What's the point of generators when they are no more efficient than
streams? I think this is Mark's argument.

My argument wasn't that leaving out SRFI 121 from Guile would make
Guile any better but that postponing the inclusion until an efficient
implementation is provided may make Guile better. But that means that
the sheer number of supported SRFIs is no measure for the quality of
an implementation.

> That is not at all the case, at least not for the generators I have added to SRFIs.  Generators are just procedures that obey a protocol; there is no need to make use of any part of the SRFI in order to provide them.  This is not the case with SRFI 41 streams.

Replace "procedure" by "stream" and the same applies to SRFI 41.
Instead of "lambda" one would use "stream-lambda".

>> And without a proof that SRFI 41's streams cannot be made nearly as
>> efficient as generators, it would have befitted Scheme as a functional
>> language to replace generators by streams. Haskell shows that
>> efficient implementations of streams are possible. But that's a
>> different area needing improvement.
>
>
> Scheme is NOT a functional language in the sense of Haskell.  It is a multi-paradigm language that, until R7RS-large, did not contain any higher-order functions beyond map, and did not contain any mutable data structures.  It still doesn't have pattern matching, though that is probably coming, and though it has something similar to the way Haskell implements type classes, there is no generalization over them.

Pattern matching is orthogonal to functional programming as are type classes.

My point is that while Scheme is a multi-paradigm language, it has
been discouraging mutability (through "set!", etc.). The usual
programming style is inherently functional and not imperative. SICP
doesn't even look at mutability in the first chapters. The difference
in the Scheme loop constructs (using tail recursion) and looping
constructs in C, etc. is obvious.

Now generators are inherently imperative (they cannot be pure), while
streams are the immutable counterpart. As long as both constructs have
the same efficiency, there's no reason to choose generators over
streams.

> The purposes of R7RS appear in the WG2 charter.  "Make Scheme into a functional language" is not one of them.  Much of my effort lately has gone into supplementing Scheme with the conventional equipment of a functional language, but without changing its nature.

Scheme, at least the Scheme presented in SICP, *is* a functional
programming language and has been a functional language.

> What is befitting to Scheme is to provide support for all programming paradigms.

That's okay. But it doesn't mean that all paradigms should be equally
well supported or encouraged. Scheme has "set!", but there has been
consensus that avoiding "set!" when reasonably possible usually
results in better (or at least more idiomatic) code.