On Sun, May 17, 2026 at 12:39 AM Peter McGoron <xxxxxx@mcgoron.com> wrote:

> 1. Is there a reason to require bytevectors as the input/output state
> representation?

Is there a reason to allow any other representation?  Bytevectors are
universal.  If the internal representation is allowed to be an
arbitrary datum, you need to use `write` and `read` to persist it; if
it's a bytevector, persistence in binary or textual formats is
trivial. Of course, the library can convert from the bytevector to a
bunch of 64-bit integers or whatever it needs.

> There is no guarantee that any bytevector would be a
> valid input (it may not be structured properly or may not be of the
> correct length).

Sure. The idea is not that you can pass just any bytevector; the
bytevector would come from a call to random-port-state on some port
from the same library.

> Ports
> should also export some predicate to check that initializing the port
> with a datum value is OK (won't result in an exception being raised)

That seems plausible, but it's the library, not the port, that should
provide this predicate, because we don't allow ports to be
reinitialized; they are initialized when created.

>
> 2. > There is no requirement that the data contained in or read from an
> initializer be a state representation extracted with random-port-state:
> make-random-port must support initializing a port from arbitrary data.
>
>     I don't understand this sentence.

I agree that this doesn't make sense.  It's one thing to require that
a port must be initializable from an infinite stream of arbitrary
data,, because if the data constitute a weak key (so to speak) it can
be discarded and the implementation can ask for more bytes.  But are
we to require that a bytevector of length 1 can initialize an
arbitrary algorithm?  Clearly not.

>     If the same equal? argument had defined behavior in a previous
> version, and fails to have that in a future version, that is a major API
> breakage. I don't that's something that can be treated at the standard
> API level. Ideally, an implementation would add another library, or
> treat the previous data in a special way, which will depend on specifics.

I agree: that's a change to the major version of the library, or to
another library altogether.