On 2026-07-09 23:50, Wolfgang Corcoran-Mathe wrote:
> The thing that bothers me about this idea is that reading from or
> setting the position of P after calling 'input-port->cyclic-port' (or
> whatever) on it may change the state of the cyclic port.  This is
> already an issue (which I forgot to address in the first draft) with
> string- or bytevector-backed cyclic ports, but it seems a lot worse
> when the cyclic port's input is another port.  You can always pass
> 'open-cyclic-input-bytevector' a copy of a bytevector, but there's no
> portable way to copy a port.
>
> For example,
>
>     (define p1 (open-input-bytevector #u8(1 2 3 4))
>
>     (define p2 (input-port->cyclic-port p1))
>
>     (read-u8 p2)  ; => 1
>     (read-u8 p1)  ; => 2 (probably)
>     (read-u8 p2)  ; => 3 (probably)
>
> And that's one of the simpler interactions.
>
> If we want this feature, in short, we have to accept ports that read
> from other ports that read from ... and the convoluted chains of side
> effects they could entail.  I'm not yet convinced it's worth it.

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"

2. "there is no guarantee that reading from both the original input port
and the cyclic port will result in any consistent sequence of reads"

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

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?

There are several possibilities...

But again, although I have proposed the idea myself, I'm also not
convinced it's really useful.

J.