On 6/4/26 15:11, Wolfgang Corcoran-Mathe wrote:
> I considered adding 'random-port?' when I first started writing the
> SRFI.  I think it can work if, as you say, we provide a 'random-port?'
> procedure for each library. We then have to decide whether> 'foo:random-port?' is true only when applied to random ports from the
> (srfi 271 ... foo) library.  (I think it would have to be, to be of any
> use at all.)
My thinking is that in some implementations, acting `random-port-state`
on a port that was not made with that libraries make-random-port is an
error, R7RS style. So there should be a predicate to guard against that
to make sure your program doesn't execute undefined behavior.

 > Could this monomorphism pose an implementation difficulty?

Perhaps an implementation could make all random ports a uniform data
structure. Adding this predicate would prevent that strategy. I don't
think that's a big loss, though, you just add an extra field containing
an ID for that random port type.

 > 'random-port-state?' poses the same challenge, but in this case it's
easily solved: simply wrap the state vector (or whatever) in a record
type and you get a library-exclusive 'random-port-state?' for free. This
isn't an option with random ports, except in implementations that allow
defining new port types.

I wasn't thinking that random port states has to be of a disjoint type.
Here is an example. Let's say that the serialized state for your RNG is
a 4 element long u64vector that is not all zero. Then

     (define (random-port-state? obj)
       (and (u64vector? obj)
            (= (u64vector-length obj) 4)
            (not (equal? obj #u64(0 0 0 0)))))

There might be two random ports that have the same set of state
representations. In that case the other library's `random-port-state?`
will return #t to the serialized state of the first library, but that's
fine: it's just asking if its a valid initializer.

-- Peter McGoron