On 2026-06-04 15:31 -0400, Peter McGoron wrote:
> 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.

You're right.  I'll add it.

> 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.

I think we can leave the definition of 'random-port?' a little
loose: it might not uniquely identify the ports from its own
library, but, if it returns true on an object, you can safely apply
'random-port-state' to that object.  This may be enough to leave the
door open for implementations with an "umbrella" random-port type.
(I'm not entirely sure.)

One further question I'm now considering is whether 'random-port?'
should be add to the randomized library interface as well.  There
are no accessors there to guard with it, but it would be useful in
implementations that make random ports disjoint from other types.  In
any case, it seems a bit strange for a predicate with such a general
name to appear in only some random port libraries.

Thanks for these suggestions.

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