Thanks for the incisive questions.  They all relate to the same
issue, I think.

On 2026-05-17 00:37 -0400, Peter McGoron wrote:
> 1. Is there a reason to require bytevectors as the input/output
> state representation? 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).

Considering that a binary blob is the bluntest instrument, I'd better
have a good reason for using it as a state representation, right?

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.  Indeed, the SRFI uses this property to specify
the behavior of 'make-random-port' (in its determinized form) when
it is called without an initializer.  However, it also gets us into
trouble, since, as you note, a bytevector can contain anything.

The SRFI would be simplified quite a bit if we adopted opaque but
representable random-port states.  For example, 'make-random-port'
would simply take a state value (obtained with 'random-port-state') as
initializer, or be called without arguments.  In the latter case, the
port must be given a random initial state.  (The specification might
suggest building this state with entropy provided by a randomized
random port.)  There would be no need to worry about the length or
form of the initializer.

That sounds very nice.  So is there anything equally nice about
bytevectors that I'm missing?

(By the way, here's another downside of the current, permissive
'make-random-port' specification:

    ;; Evaluates to a new port with the same state (and which produces
    ;; the same sequence) as port1.
    (make-random-port (random-port-state port1))

    ;; Evaluates to a new port with a random state.
    (make-random-port port1)

These expressions are somewhat similar, but they do very different
things.  I can see the "rushed or incautious programmer" mixing them
up.)

> 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.  It isn't exactly clear what "initializing a port from
arbitrary data" means.  A more precise, or at least more verbose,
version might be "if the *initializer* does not contain a representation
of a valid random-port state, then 'make-random-port' 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*,
then applies an unspecified transformation to convert this data into
a random-port state."  (In practice the "unspecified transformation"
might be very simple, but endianness, at least, would be a factor.)

The only practical use I can see for this is to initialize a port to
a random state.  Per the specification, I could use the following clumsy
code to make two ports that produce the same sequence:

    (let* ((state-length
            (call-with-port
             (make-random-port)
             (lambda (p)
               (bytevector-length (random-port-state p)))))
           (seed (make-bytevector state-length 69)))
      (values (make-random-port seed)
              (make-random-port seed)))

Here, *seed* is not a valid state, just arbitrary data.  But this is
of course much worse than:

    (let ((port1 (make-random-port)))
      (values port1
              (make-random-port (random-port-state port1)))).

All of this is, again, an argument against binary initializers.

> 3. >  What if the state representation for a given library changes
> slightly between versions
>
>    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.

I agree.  The importance of this issue was magnified for me, I think,
because of my related concerns about the amorphous binary format.

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