Peter,

On 2026-06-19 13:48 -0400, Peter McGoron wrote:
> 1. Some instances of "random-port" as a phrase should probably be
> "random port".

You're probably right.  I'll do some more proofreading.

> 2. Chacha is a deterministic RNG, so it might be better to move it
> to the determinized section. `(srfi 271 randomized hwrng)` for the
> Linux kernel's /dev/hwrng interface
> <https://docs.kernel.org/admin-guide/hw_random.html> is be a better
> example.

I could see a implementation doing it both ways.  People will probably
use these somewhat costly stream ciphers when they need crypto-quality
randomness.  Disallowing port initialization from a known (possibly
low-entropy) state may be a Good Thing in those security-relevant
cases.  I don't expect everyone to agree on this, however: "don't use a
bogus state, then!" is another possible attitude.

I might move these libraries to the determinized section, with a note
to the effect that some implementations might provide randomized
ChaCha libraries instead (or in addition).

> 3. In the description of `make-random-port`, I would explicitly note
> that implementers may allow other objects to initialize random
> ports, and that they should raise an initialization error if the
> object cannot initialize a port.

I see no need for this.  'make-random-port's behavior on other objects
is undefined, and "undefined" means "open to expansion".

> 4. I would still like to see the “trivial” random port that just
> outputs a given bytevector cyclically. Such a port isn't possible to
> implement in R7RS and can be used to seed all but the most
> pathological ports with fixed high-entropy data.

I think these are useful, but slightly outside of SRFI 271's scope.
There is room for further random-port SRFIs.

> 5. I would add a code example to show the deterministic behavior of
> the ports.
>
> [snip]

Fine.  This is a good example, and the SRFI is lacking in examples.

Thanks very much for the review.

--
Wolfgang Corcoran-Mathe  <xxxxxx@sigwinch.xyz>