John,

Thanks for your comments.

On 2026-05-14 02:08 -0400, John Cowan wrote:
> 1) Definition of :"random port" should say "must not" (a random port
> that returns an eof-object is broken).

I agree.  I can't think of a case in which it makes sense to get EOF
on a random port.

> 2) "Determinize" means "make deterministic" per Wikt.  I suggest
> "deterministic", but see my discussion below of an alternative library
> structure.

I'm still not entirely happy with the naming, but I think 'determinized'
is an adequate description of seedable ports.  'Deterministic' is
a bit confusing, since the intended distinction is not between the
behavior of the ports as random-number generators, but between their
state interfaces.  'Randomized' ports are opaque; 'determinized' ports
have the additional state-inspection and initialization interface.

* * *

The following relates to your proposal on the R7RS wiki.

First, I'll note that random ports fall somewhere on two axes:

                    'randomized'
                         |
    cryptographic -------+------- bogographic
                         |
                   'determinized'

The X axis is intended to capture the range of RNG quality: on the
far left you'd have hardware quantum noise RNGs, and on the far right
you'd have truly bogus PRNGs that always return 4, say, or the last
digit of the current year.  The Y axis is a binary choice: a port
may or may not expose an internal state.

In SRFI 271, only the Y axis (the randomized / determinized dichotomy)
is represented, because it seems to be impossible to represent the
crypto / bogo range reliably.  (Without a good source of entropy
they're all bogus.)  But it's important to recognize that these axes
are orthogonal.  "Determinized" ports aren't necessarily bogus, of
course.  It also wouldn't be contradictory for an implementation to
provide randomized and determinized versions of the same PRNG.  Indeed,
it might be useful to have the same generator used "in the wild"
(where exposed PRNG state may be undesirable) available for testing.

From John's wiki proposal:
> But for a random port to be cryptographically *usable*, it must be
> both generated by a  cryptographically safe algorithm and seeded
> from a genuinely random source ...  It does not matter whether
> the ultimate source of seeds has another cryptographically safe
> algorithm in front of it or not.
>
> Therefore, I think the libraries should be structured as follows;
>
> `(srfi 271 base)` provides a single random port [name needed]
> suitable for seeding safe algorithms, but also usable for seeding
> fast algorithms, drawn from one of the sources above or some
> comparable source.

I believe there is an early-21st-century assumption here, namely that we
will always be seeding (fast) PRNGs from (slow) entropy sources.  I can
imagine a future in which every machine has a fast hardware RNG, and no
one bothers with seeded PRNGs unless they have a need for blazing speed
and don't mind pseudorandomness (e.g. in a game).  In such a future,
the collection of "fast", "safe", etc. PRNG libraries would be little
more than a toy box.  (Of course, those toys might still be useful for
testing, assuming they implement the SRFI 271 determinized interface.)

Consider this (dull) science fiction if you wish, but it's not a hard
scenario to imagine, and I'd rather plan to make the SRFI robust in
the face of conceivable changes in practice.

Even with the SRFI's current higher level of abstraction you can
still have this "base" / "fast" / "safe" division if you so choose.
(I would avoid using the name 'safe', but anyway.)  You would provide:

    (srfi 271 randomized)        ; this is your "base" library
    (srfi 271 determinized)      ; alias of the "safe" library
    (srfi 271 determinized safe)
    (srfi 271 determinized fast)

While it may be wordier, is this so different from what you have in
mind?

* * *

A few other thoughts:

Your message suggests to me that, in its current form, the SRFI
isn't quite conveying the abstraction I had in mind.  I'll have to
think about how to improve the presentation.  Random ports are very,
very simple, as ports go: in general, beyond being end-of-file-less,
nothing is required of them beyond what the Reports require of all
binary input ports.

I'm concerned that determinized ports may be distracting people from
this central abstraction.  Determinized random ports, even though they
take up a lot of specification space, are really a niche concern.
(To emphasize this view, we could make (srfi 271 determinized) an
optional library.)

Looking at the axes I sketched above, one might wonder why "randomized"
random ports are tied to an expectation of high entropy in the
SRFI.  The answer is that I can't think of a good reason to provide
internal-entropy (another name) random ports that aren't high-entropy.
This violation of orthogonality is thus made to (hopefully) ensure
that (srfi 217 randomized) (and, by alias, (srfi 217)) provides the
best-quality randomness your Scheme has access to.

I wish we could just have (srfi 217 fast) and (srfi 271 safe) and
call it a day.  But, as I am continually learning, this is a very
complex and subtle area.

Wolfgang

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