more comments Peter McGoron (17 May 2026 04:39 UTC)
Re: more comments Wolfgang Corcoran-Mathe (17 May 2026 20:33 UTC)
Re: more comments Peter McGoron (17 May 2026 21:21 UTC)
Re: more comments Wolfgang Corcoran-Mathe (18 May 2026 00:54 UTC)
Re: more comments Shiro Kawai (18 May 2026 11:52 UTC)
Re: more comments John Cowan (18 May 2026 13:46 UTC)
Re: more comments Shiro Kawai (18 May 2026 17:21 UTC)
Re: more comments Wolfgang Corcoran-Mathe (18 May 2026 18:03 UTC)
Re: more comments Peter McGoron (18 May 2026 15:33 UTC)
Re: more comments Vincent Manis (he/him) (18 May 2026 16:41 UTC)
Re: more comments Shiro Kawai (18 May 2026 17:13 UTC)
Re: more comments Peter McGoron (18 May 2026 18:28 UTC)
Re: more comments Shiro Kawai (18 May 2026 18:42 UTC)
Re: more comments Peter McGoron (19 May 2026 02:12 UTC)
Re: more comments Shiro Kawai (19 May 2026 03:16 UTC)
Re: more comments Wolfgang Corcoran-Mathe (18 May 2026 16:59 UTC)
Re: more comments Shiro Kawai (18 May 2026 17:08 UTC)
Re: more comments John Cowan (18 May 2026 06:17 UTC)
Re: more comments Peter McGoron (18 May 2026 11:30 UTC)
Re: more comments John Cowan (18 May 2026 13:21 UTC)
Re: more comments Wolfgang Corcoran-Mathe (18 May 2026 17:19 UTC)

Re: more comments Peter McGoron 18 May 2026 15:32 UTC

On 5/18/26 07:52, Shiro Kawai wrote:
> Limiting the initializer to infinite binary ports sounds good,
> especially because we can delegate the responsibility for the required
> data length to the each PRNG implementation.  But I need a guarantee
> that an arbitrary embed hardcoded number (e.g. a port that repeatedly
> generates a certain hardcoded sequence of bytes) works across all
> implementations.  The use case is reproducible tests described in
> https://srfi-email.schemers.org/srfi-271/msg/40080987/ <https://srfi-
> email.schemers.org/srfi-271/msg/40080987/> .

Perhaps the specification can be extended such that if `#t` is passed as
an initializer, then the random port is initialized to a fixed default
state.

-- Peter McGoron