LGTM

On Tue, May 5, 2026 at 12:31 PM Wolfgang Corcoran-Mathe
<xxxxxx@sigwinch.xyz> wrote:
>
> 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>