On 2026-07-10 09:16 -0300, Jeronimo Pellegrini wrote:
> Neither am I, but I still feel like "maybe this can be useful"
> (thinking about SRFI 271 for example). Perhaps with clearly defined
> semantics, as
>
> 1. "input-port->cyclic-port will read all N bytes or characters at
> once (atomically) from the input port before returning the cyclic
> port"

This is what I meant by "slurping".  With these semantics,
(input-port->cyclic-port PORT N) (or whatever) becomes equivalent to

    (let ((vec (read-bytevector N PORT)))
      (when (eof-object? vec)
        (error ...))
      (open-cyclic-input-bytevector vec)),

or to the analogous string version.  This is pretty easy to write, and
probably doesn't warrant adding another procedure.

> 3. "input-port->cyclic-port will immediately make the input port
> unavailable for reading by any process" (really bad, but a possible
> semantics)

Yes.  It's essentially the old "linear update" idea from SRFIs 1, 13,
etc., but, as I wrote before, it's worse here because you can't copy
ports.

> By the way... Regarding string and bytevectors, maybe it would be
> possible to adopt option (1) anove, or: restrict the operation to
> the immutable ones? Or (but breaking the principle of least
> surprise, so not good) automatically make the string o bytevector
> immutable when preparing the cyclic port?

Adopting (1) in the string and bytevector cases would be equivalent to
saying that these procedures operate on a copy of their arguments, thus
guaranteeing that later argument mutation won't affect cyclic port
output.  I was going to make this change, but realized that, in R6 and
R7, the effect of mutating the argument of 'open-string-input-port',
'open-input-string', etc. is explicitly left unspecified.  (See R7RS
§6.13.1 and R6RS standard libraries §8.2.7.)  I think the SRFI should
probably follow the Reports here.

It would be nice to restrict string and bytevector input ports to
immutable inputs in general.  But of course no Report has yet given us
a way to create or detect an immutable object.

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