Hi Peter, and thanks very much for the review.

On 2026-05-03 15:48 -0400, Peter McGoron wrote:
> 1. In "random port states":
>
> > SRFI 27 allows random-source states to be manipulated as opaque
> > objects, which does most of the job — you can save the sate of a
> > SRFI 27 source and restore it later, **although the SRFI doesn’t
> > guarantee that states support an equivalence relation or have datum
> > representations**.
>
>    SRFI 27 requires that states have "external representations," so
> the bolded sentence is incorrect.

I completely overlooked that last sentence of SRFI 27's
'random-source-state-ref' spec, probably because it seems to contradict
the previous statement ("the only portable use of [a random source
state] is as an argument to 'random-source-set!']").  At the very
least, you can portably read, write, and compare datum representations
of an object with such a representation.

Those are just lame excuses, though.  I'll rewrite the quoted paragraph.

>    Also "sate" -> "state".

Good catch.  Still waiting on semantic mode for aspell(1).

> 2. "An error is signaled" the SRFI should have a predicate for
>    these errors.

Should it, or should we change the specification to use an R6RS
condition type?  So far the SRFI is written in R7-ese, but condition
types are probably the way forward.

> 3. "random-port-state" This should specify if it shares state
>    or is newly allocated.

I'm going to go with John's idea here, I think--either it's undefined
to mutate the result or, as R6RS would have it, the result is "an
immutable bytevector" (and mutating it SHOULD be an assertion
violation).

> 4. SRFI 27 also exposes procedures to generate integers and inexact
> reals. Generating integers from bytes is straightforward, but
> inexact reals are more difficult and implementation specific.

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

Speaking of which, I need to rewrite the "compatibility" section.
It's clearly afflicted with tunnel-vision; you can certainly implement
SRFI 27 random sources on top of random ports.

> 5. If I pass "initializer" to a crypto port, will it just get
>    ignored?

Yes.  This is what I meant by "The optional *initializer* argument
is used only by [make-random-port procedures exported by] repeatable
libraries," but I agree that this should be made clearer.

Thanks again.

Wolfgang

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