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 17 May 2026 21:20 UTC

 > After some thought, the only advantage I can see is that the
bytevector interchange format for states allows us to seed random ports
from other random ports.

I don't think that the bytevector format is required for seeding random
ports from other random ports.

A random port is an (effectively) infinite source of bytes. A random
source constructor takes some number of bytes from that random port and
converts it into its own internal representation. The required structure
of bytes is abstracted from the user, and so is the number of bytes (a
random port constructor could even take a variable number of bytes: it
doesn't matter, the source is infinite).

Hence there is no requirement that ports be able to exchange
byte*vectors* with eachother, just infinite bytes. The other things that
can be passed to a random port constructor are implementation defined,
except whatever datum comes out of the random-port-seed procedure.

 > draws an
amount of data (the exact number of bytes is given by the length of
the bytevector returned by 'random-port-state') from *initializer*

With random port initializers the information about the length is
unnecessary, because a finite amount can always be taken from an
infinite source. Hence there is no need to specify this seeding with
bytevectors, they can be lumped in with the other implementation-defined
initialization objects.

__________________________________

I will give a concrete example. The xoshiro256++ generator uses a 64*4
bit seed. Notably, the seed must not be everywhere zero, so an arbitrary
bytevector of that length will not work. This information can be
abstracted away from the user though: given a random binary input port,
it can pull bytes until it gets a combination that is not everywhere
zero (which is technically possible, even if extremely unlikely).

There is no need for a bytevector interface in this scenario. The port
could be implemented with u64vectors as the state representation, which
the port would trust on initialization as the fast-path (no u64vector it
will ever return from `random-port-state` will be all zeros, because it
rejects those in random generation).

-- Peter McGoron