Proposed solution to the "predetermined states" problem Wolfgang Corcoran-Mathe (22 May 2026 23:18 UTC)
Re: Proposed solution to the "predetermined states" problem Wolfgang Corcoran-Mathe (22 May 2026 23:26 UTC)
Re: Proposed solution to the "predetermined states" problem Peter McGoron (23 May 2026 00:02 UTC)
Re: Proposed solution to the "predetermined states" problem Peter McGoron (23 May 2026 01:18 UTC)
Re: Proposed solution to the "predetermined states" problem Peter McGoron (23 May 2026 13:44 UTC)
Re: Proposed solution to the "predetermined states" problem Wolfgang Corcoran-Mathe (23 May 2026 15:15 UTC)
Re: Proposed solution to the "predetermined states" problem Wolfgang Corcoran-Mathe (23 May 2026 16:28 UTC)
Re: Proposed solution to the "predetermined states" problem Peter McGoron (23 May 2026 17:00 UTC)
Re: Proposed solution to the "predetermined states" problem Peter McGoron (23 May 2026 17:02 UTC)
Re: Proposed solution to the "predetermined states" problem Wolfgang Corcoran-Mathe (24 May 2026 17:15 UTC)

Proposed solution to the "predetermined states" problem Wolfgang Corcoran-Mathe 22 May 2026 23:18 UTC

Hi all,

I've been thinking about Shiro Kawai’s problem[1] of storing a known
random-port state (or states) for use in each run of a test suite.
While I've suggested exporting a "sample" state from each determinized
port library, I find this solution unsatisfactory.  The following
alternative is an elaboration of something I suggested in an earlier
response to Shiro.

There is a (mostly) reliable way to get a number of known random-port
states without reading seeds from external files, but it requires some
unusual input ports.  If *cp* is a port that produces a single number
infinitely, then you can pass *cp* to 'make-random-port' and get a
port with the same initial state each time.  If you want multiple
random ports with different reproducible states, just initialize each
one with a port producing a different constant stream.

As I noted, these "infinite constant ports" are unusual; I don't think
there's a way to construct one in standard Scheme.[2]  But they are,
in a sense, degenerate random ports, and so a system that provides
SRFI 271 could certainly provide an "all Ns" port.  The constructor
for such a port would be quite simple:

(make-constant-port byte) → binary-input-port

You could hardcode some of these ports into your testing harness:

    (define seeding-port (make-constant-port 4))

What do you think of this approach?  I doubt constant ports belong
in SRFI 271, but they are conceptually simple and could be easily
specified in a small related SRFI.

[1] https://srfi-email.schemers.org/srfi-271/msg/40080987/

[2] Of course, you can approximate them with a hack:

    (define (make-finite-constant-port k byte)
      (open-input-bytevector (make-bytevector k byte)))

Just pick a big k and hope for the best.

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