Establishing a Scheme registry Lassi Kortela (31 Jul 2020 08:14 UTC)
Re: Establishing a Scheme registry Marc Nieper-Wißkirchen (31 Jul 2020 08:39 UTC)
Re: Establishing a Scheme registry Lassi Kortela (31 Jul 2020 08:49 UTC)
Prior art: SRFI 97 Lassi Kortela (31 Jul 2020 08:59 UTC)
Re: Prior art: SRFI 97 Marc Nieper-Wißkirchen (31 Jul 2020 09:18 UTC)
Re: Prior art: SRFI 97 Marc Nieper-Wißkirchen (31 Jul 2020 09:20 UTC)
Re: Prior art: SRFI 97 Lassi Kortela (31 Jul 2020 09:39 UTC)
Re: Prior art: SRFI 97 Marc Nieper-Wißkirchen (31 Jul 2020 09:58 UTC)
Re: Prior art: SRFI 97 Lassi Kortela (31 Jul 2020 10:13 UTC)
Re: Prior art: SRFI 97 Marc Nieper-Wißkirchen (31 Jul 2020 10:18 UTC)
Python PEPs Lassi Kortela (31 Jul 2020 10:23 UTC)
Re: Python PEPs Marc Nieper-Wißkirchen (31 Jul 2020 11:12 UTC)
Re: Python PEPs Lassi Kortela (04 Aug 2020 07:04 UTC)
Re: Python PEPs hga@xxxxxx (04 Aug 2020 09:28 UTC)
Re: Prior art: SRFI 97 Marc Nieper-Wißkirchen (31 Jul 2020 13:31 UTC)
Re: Establishing a Scheme registry Marc Nieper-Wißkirchen (31 Jul 2020 09:13 UTC)
Re: Establishing a Scheme registry John Cowan (01 Aug 2020 03:49 UTC)
Re: Establishing a Scheme registry Marc Nieper-Wißkirchen (01 Aug 2020 06:29 UTC)
Re: Establishing a Scheme registry John Cowan (01 Aug 2020 13:19 UTC)
Re: Establishing a Scheme registry Marc Nieper-Wißkirchen (01 Aug 2020 13:48 UTC)
Re: Establishing a Scheme registry Amirouche Boubekki (01 Aug 2020 13:55 UTC)
Re: Establishing a Scheme registry Arthur A. Gleckler (31 Jul 2020 20:09 UTC)
Re: Establishing a Scheme registry hga@xxxxxx (31 Jul 2020 20:34 UTC)
Re: Establishing a Scheme registry John Cowan (01 Aug 2020 01:58 UTC)
Re: Establishing a Scheme registry Amirouche Boubekki (31 Jul 2020 09:04 UTC)
Re: Establishing a Scheme registry hga@xxxxxx (31 Jul 2020 20:52 UTC)
Re: Establishing a Scheme registry Lassi Kortela (01 Aug 2020 19:50 UTC)

Re: Establishing a Scheme registry Marc Nieper-Wißkirchen 01 Aug 2020 13:47 UTC

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