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.
Ah, okay. Your wording was ambiguous between the two meanings.
But that means that
the sheer number of supported SRFIs is no measure for the quality of
an implementation.
I don't think anyone would claim that it is.
> 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".
Lambda is a standard part of Scheme; using it introduces no dependencies. The same cannot be said of stream-lambda. Using generators involves a minimal ontological commitment, and in particular there is no dependency on SRFI 121. It is for similar reasons that I generally define conversions to and from lists, strings, and vectors rather than their immutable counterparts.
> 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.
Typo on my part: I should have said it did not contain *immutable* data structures.
My point is that while Scheme is a multi-paradigm language, it has
been discouraging mutability (through "set!", etc.).
It's true that Schemers customarily treat lists (or pairs generally) as immutable, and the same with strings; this is something I do myself. But vectors are often treated mutably, and records may be either mutable or immutable: they were the first kind of immutable types to be introduced to the Scheme standards in R6RS.
However, records are merely the successors to a very important classical style of Scheme programming called "poor man's objects", in which fields are emulated by the local variables of a procedure. which necessarily involves set!. Lastly, call/cc is imperative, and nobody could say that it is not a fundamental part of Scheme.
SICP doesn't even look at mutability in the first chapters.
The point of SICP is to teach (a certain style of) programming, not to teach Scheme. TSPLv4, which *is* intended to teach Scheme, has an excellent pedagogical presentation of assignments and their vices and virtues in section 2.9, part of the "Getting Started" chapter. See <
https://www.scheme.com/tspl4/start.html#./start:h9>.
Now generators are inherently imperative (they cannot be pure), while
streams are the immutable counterpart.
That turns out not to be the case. Generators are imperative either explicitly or because they depend on call/cc; streams are not explicitly imperative, but are based on the `delay` macro, which is again not explicitly imperative, but is required to memoize its result and therefore is also imperative under the covers. (The sample implementation of SRFI 41 uses set-car! and set-cdr! explicitly rather than `delay`.)
Scheme, at least the Scheme presented in SICP, *is* a functional
programming language and has been a functional language.
As noted, SICP isn't about Scheme: it uses a specific and limited subset of Scheme for an entirely different purpose.
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.
All mutations are equivalent to set!. For example, vector-set! changes
one location (in the sense of R[57]RS section 3.4) in the same way as set!; in vector-set!, the location is part of a numerically indexed sequence of locations, whereas in set! it stands alone. Once you start to get rid of mutation, you end up leaving Scheme-as-we-know-it behind in favor of something else.
The inventor of the language laid it all out for us on the R2RS title page:
Data and procedures and the values they amass,
Higher-order functions to combine and mix and match,
Objects with their local state, the messages they pass,
A property, a package, a control point for a catch —
In the Lambda Order they are all first-class.
One Thing to name them all,
One Thing to define them,
One Thing to place them in environments and bind them,
In the Lambda Order they are all first-class.
John Cowan
http://vrici.lojban.org/~cowan xxxxxx@ccil.orgUsing RELAX NG compact syntax to develop schemas is one of the simple
pleasures in life.... --Jeni Tennison