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

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.  SRFI
27 is based on, and exposes parts of, a specific algorithm which is
only suitable for repeatable algorithms. The MRG32k3a algorithm in the
sample implementation has a very long period (2^191 states before it
repeats), but it is not crypto-strong even if layered over a
crypto-quality random seed: 64 samples are enough to make all its
future outputs completely predictable.  Here's my analysis of SRFI 27.

Sort-of-useful procedures:

random-integer: Reasonable if you only want non-negative integers.
Negative integers are straightforward to get by mapping even results
onto non-negative integers and odd results onto negative integers, but
it's more usable to return an inclusive lower limit and an exclusive
upper limit, which provides more flexibility.  A generator of these is
provided by SRFI 194 under the name of make-random-integer-generator

random-real:  Returns an inexact number in the range 0 to 1 exclusive.
People will again want a value with different upper and lower bounds,
and will try to get it by a linear transformation, but per Goualard's
paper this does not give good results.  Instead we should have a
procedure returning an inclusive lower bound and an inclusive upper
bound.  Doesn't actually say that the results are inexact.  A
generator of these is provided by SRFI 194 under the name of
make-random-real-generator (but does not specify inexact results).

random-source-make-integers: A generator of random integers with a fixed limit.

random-source-make-reals:  A generator of real numbers.  Has the same
issues as random-real.

Basically useless procedures:

These are based on having random-state objects that are mutable boxes
wrapping SRFI 271 random ports.  This box can be produced by
define-record-type providing a single field.

make-random-source: This is like 271's make-random-port as provided by
(srfi 271 repeatable), except for not being repeatable, or like the
same procedure from (srfi 271 crypto), except for (in the sample
implementation) not being cryptographically strong.  It doesn't fit
our model.

default-random-source: Just a memoized call on make-random-source.

random-source?: The predicate of the box.

random-source-state-ref: Composes unboxing the random-state object and
SRFI 271's random-port-state.

random-source-port-set!: Replaces the contents of the random-state box
with a new random-port.

random-state-randomize!: Unclear where the new state is supposed to
come from, and requires creating a new random-port.  I'lll discuss
this point in a separate email.

random-state-randomize!: Depends on choosing two integers i and j,
which only make sense in the context of
MRG32k3a.

Rather than continuing to layer SRFI 194 over this mess, it should be
replaced by a trivially different version layered over SRFI 271.