To wrap up this discussion about random data streams:

- When SRFI 194 is finished, I will write a compatible mirror SRFI
that uses streams instead of generators. For the implementation, the
procedures "generator->stream" and "stream->generator" scheduled for
SRFI 158bis will come in handy.
- When extremely fast random number generation is required, users are
recommended to use random generators. Those who need playback or
generally functional pure data structures and algorithms are
recommended to use random streams.
- During the R7RS-large process, SRFI 194 and the corresponding stream
SRFI may go into (scheme random-generator) and (scheme random-stream),
respectively, or they both may be merged into one library.
- As discussed here, I will also write a SRFI that provides
abbreviations for the SRFI 41 procedures and syntax, e.g. scons, scar,
and scdr instead of stream-cons, stream-car, and stream-cdr,
respectively (much as we already have the prefixes "g", "r", "i", "i"
for other data types). This can later be merged with (scheme stream)
or go into (scheme sstream), for the lack of a better name.

Am Mo., 11. Mai 2020 um 21:48 Uhr schrieb Marc Nieper-Wißkirchen
<xxxxxx@nieper-wisskirchen.de>:
>
> Am Mo., 11. Mai 2020 um 21:30 Uhr schrieb John Cowan <xxxxxx@ccil.org>:
> >
> > Yes, I agree, modulo a few points.
> >
> > I already have a pre-SRFI 158bis at <https://bitbucket.org/cowan/r7rs-wg1-infra/src/default/MoreGenerators.md>.  I have just added generator->stream and stream->generator to this.
>
> Excellent!
>
> > I do not agree that one should go into SRFI 41bis and another into SRFi 158bis, for two reasons: (a) we don't put all foo->list procedures into SRFI 1bis, and (b) doing so would create a circular dependency, not in this case but in many cases.  For example, stream->lseq would require the SRFI 127bis to depend on SRFI 41, and lseq->stream would require SRFI 41bistttttttttttttttttt to depend on SRFI 127.  It is better to have datatypes interoperate using bog-standard object types like lists, vectors, and procedures.
>
> That makes a lot of sense!
>
> The more dependencies a library has, the more costly it will be to
> include it into a program. Thanks to things like `eval`, a Scheme
> linker is often not able to throw out seemingly unused parts of a
> library.