Am Sa., 1. Aug. 2020 um 15:19 Uhr schrieb John Cowan <xxxxxx@ccil.org>:

>> 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 was a left-over from the earlier discussion.

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

Promises are a standard part of R7RS-small, which is the basis for R7RS-large.

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

The question is not whether there are (only) immutable data structures
but whether it is encouraged to use the existing data structures in
non-mutable ways.

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

That's a misbelief. call/cc is not at all imperative. It's completely
functional. It just adds Peirce's law to the Curry-Howard
correspondence.

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

SICP contains a chapter about the cost of assignment not without reason.

> That turns out not to be the case.  Generators are imperative either explicitly or because they depend on call/cc; streams are not

Generators are not imperative because they depend call/cc (which is
not imperative) but because they have internal state. Look at the
number of setters required for "make-coroutine-generator".

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

While mutable data structures are needed to implement promises
efficiently, this is an implementation detail and doesn't make
promises itself imperative. Haskell isn't implemented much
differently. And any programming language running on a standard CPU is
implemented using mutable data structures.

In fact, call/cc is a good tool to measure data structures. Generators
do not work well with call/cc. Streams do. Think, for example, of the
amb macro.

So when we think that call/cc is one defining element of Scheme, a
functional programming style should be favored when it doesn't cost
anything. And that was the original question choosing between
generators and streams.

Marc