Am Sa., 1. Aug. 2020 um 05:49 Uhr schrieb John Cowan <co...@ccil.org>: > > > > On Fri, Jul 31, 2020 at 5:13 AM Marc Nieper-Wißkirchen > <m...@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.
