Functional random data streams Marc Nieper-Wißkirchen (05 May 2020 06:44 UTC)
Re: Functional random data streams Shiro Kawai (05 May 2020 09:10 UTC)
Re: Functional random data streams Shiro Kawai (05 May 2020 09:12 UTC)
Re: Functional random data streams Marc Nieper-Wißkirchen (05 May 2020 09:26 UTC)
Re: Functional random data streams Marc Nieper-Wißkirchen (05 May 2020 09:35 UTC)
Re: Functional random data streams Shiro Kawai (05 May 2020 10:02 UTC)
Re: Functional random data streams Marc Nieper-Wißkirchen (05 May 2020 10:58 UTC)
Re: Functional random data streams John Cowan (05 May 2020 13:29 UTC)
Re: Functional random data streams Marc Nieper-Wißkirchen (05 May 2020 13:47 UTC)
Re: Functional random data streams Shiro Kawai (05 May 2020 19:45 UTC)
Re: Functional random data streams Marc Nieper-Wißkirchen (05 May 2020 20:00 UTC)
Re: Functional random data streams Shiro Kawai (05 May 2020 20:23 UTC)
Re: Functional random data streams Marc Nieper-Wißkirchen (06 May 2020 17:43 UTC)
Re: Functional random data streams John Cowan (06 May 2020 19:32 UTC)
Re: Functional random data streams Marc Nieper-Wißkirchen (06 May 2020 19:39 UTC)
Re: Functional random data streams John Cowan (06 May 2020 21:11 UTC)
Re: Functional random data streams Marc Nieper-Wißkirchen (07 May 2020 06:10 UTC)
Re: Functional random data streams John Cowan (08 May 2020 18:23 UTC)
Re: Functional random data streams Marc Nieper-Wißkirchen (08 May 2020 18:41 UTC)
Re: Functional random data streams Marc Nieper-Wißkirchen (09 May 2020 08:31 UTC)
Re: Functional random data streams John Cowan (11 May 2020 19:30 UTC)
Re: Functional random data streams Marc Nieper-Wißkirchen (11 May 2020 19:48 UTC)
Re: Functional random data streams Marc Nieper-Wißkirchen (20 Aug 2020 09:39 UTC)
Re: Functional random data streams John Cowan (20 Aug 2020 16:00 UTC)
Re: Functional random data streams Marc Nieper-Wißkirchen (20 Aug 2020 18:23 UTC)
Re: Functional random data streams Arthur A. Gleckler (20 Aug 2020 20:18 UTC)
Re: Functional random data streams Marc Nieper-Wißkirchen (20 Aug 2020 20:27 UTC)
Re: Functional random data streams Arthur A. Gleckler (20 Aug 2020 23:08 UTC)
Re: Functional random data streams Marc Nieper-Wißkirchen (21 Aug 2020 07:01 UTC)

Re: Functional random data streams Marc Nieper-Wißkirchen 06 May 2020 17:42 UTC

Generator operations use "g" as their prefix; lazy sequences use "l"
as their prefix. (Transducers use "r", immutable pairs "i", etc.)

Wouldn't it make a lot of sense to reserve the prefix "s" for streams,
so that we have "spair?", "scar", "scdr" and, in SRFI 194,
"sweighted-sampling"? For the former, it will need a SRFI 41*, of
course.

Am Di., 5. Mai 2020 um 15:29 Uhr schrieb John Cowan <xxxxxx@ccil.org>:
>
>
>
> On Tue, May 5, 2020 at 2:44 AM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:
>
>> As long as efficiency reasons (that may be the case for particular
>> implementations) do not stand in the way, from a purely functional
>> point of view, the streams of SRFI 41 are preferable over the SRFI 158
>> generators.
>
>
> I have no objection to this, though I doubt the reason given.  The very essence of random numbers is that they aren't pure and functional: they depend not only on the state of the machine, but on the state of the physical universe.  Putting them into a  pure data structure doesn't really change that.
>
> It would be appropriate to provide versions not only for SRFI 41 streams, but also for SRFI 127 lazy sequences.  The three SRFIs were intended (by me, not by Philip Bewig) to form a gradient:
> streams are heavyweight and functional, lazy sequences are middleweight and present a functional interface alongside a visibly stateful one; generators are lightweight, stateful. and without memory.
>
> However, I don't know if Arvydas is willing to add the two new sets of implementations that would be required.  If he is, or if someone else will volunteer for it, I will be glad to provide the relevant revision of SRFI 194.  (I see no reason to push them off to a separate SRFI at this stage.)
>
>
>
> On Tue, May 5, 2020 at 6:02 AM Shiro Kawai <xxxxxx@gmail.com> wrote:
>
>>
>> For example, srfi-133 vector-unfold is not restart safe (it doesn't specify so, and reference implementation isn't).
>
>
> A post-implementation note would be straightforward, and so would a change to the sample implementation of vector-unfold.
>
>
>
> John Cowan http://vrici.lojban.org/~cowan xxxxxx@ccil.org
> Verbogeny is one of the pleasurettes of a creatific thinkerizer.
>         --Peter da Silva
>