On 2026-05-04 22:15 -0400, John Cowan wrote:
> On Mon, May 4, 2026 at 3:44 PM Wolfgang Corcoran-Mathe <xxxxxx@sigwinch.xyz> wrote:
>
> > I am strongly of the opinion that this SRFI shouldn't provide any
> > procedures for drawing random data. The idea is to build all of
> > that on top, probably with this structure:
> >
> > SRFI 194
> > --------
> > SRFI 27 ↑ This way up.
> > --------
> > SRFI 217 [oops]
> While it's certainly possible to shim SRFI 27 over SRFI 271 (and hey,
> the SRFI numbers match up), I don't think it makes much sense.
After studying SRFI 27 a bit more and trying to figure out the most
congenial way of layering it over (multiple!) SRFI 271 libraries,
I agree--it's a poor fit. As you detailed, there are several
not-so-useful random-source procedures which don't fit random
ports. And, crucially, if your 27-on-top-of-271 library provides the
default-random-source "parameter", you have to build upon a specific
SRFI 271 library. (No library functors in Scheme!) Assuming you want
a strict library hierarchy like the one above, you'd get something like
(srfi 271 random repeatable xoshiro256++) --> (srfi 27 xoshiro256++)
(srfi 271 random repeatable xoshiro256**) --> (srfi 27 xoshiro256**)
⋮ --> ⋮
which is just awful.
So as you say,
> Rather than continuing to layer SRFI 194 over this mess, it should be
> replaced by a trivially different version layered over SRFI 271.
This is also my thought. Provide a library of random-drawing
procedures, each of which takes a port argument. (If you
s/random source/random port/g, this is very much like the foundation
of SRFI 194.) This solves the parameterized-library problem, and you
can have just one random-generator library to go with N random-port
libraries. (If you want a default-random-port parameter, it can just
be a "crypto" / "entropic" port--that library will always be available.)
If this sounds good, I'll write a more detailed sketch to add to the
SRFI document.
--
Wolfgang Corcoran-Mathe <xxxxxx@sigwinch.xyz>
