On 2026-07-09 14:13 -1000, Shiro Kawai wrote:
> As the support of srfi-181/192 varies, it doesn't guarantee the
> availability of positioning for users, unfortunately.  I'm thinking more
> for implementers; mentioning to it in the srfi text reminds them to provide
> it if possible.  The portable code should use port-has-port-position? etc.
> anyway.

I agree.  The next draft will include a reminder to provide positions
if they're available at all.

> Regarding representation of positions: R6RS and srfi-181 grant great
> flexibility for implementations, and conversely, we can't overspecify it in
> this srfi.  For a binary port, it is only specified as "index of the
> position at which the next byte would be read from or written to the port
> as an exact non-negative integer object."   Both cyclic and cumulative
> index satisfy this---the user code that assumes the position is
> monotonically increasing may choke on cyclic index, but that's not even
> guaranteed in the first place.  For a textual part it can be anything the
> implementation chooses.
>
> I think we can just say the returned position should follow R6RS/srfi-181
> spec, at best.

First of all, I agree that the SRFI shouldn't require anything more of
cyclic port positions than that they follow SRFIs 181 & 192.  One
shouldn't assume they increase monotonically, or, in the case of
string-port positions, that you know anything about their
representation at all.

But it's interesting to note that you can provide a
monotonically-increasing position for a cyclic port.  Indeed, this is
what I did in the sample implementation: the port position is congruent
modulo the input string or bytevector length to the current byte or
character index.  (It seemed like the natural thing at the time.  Maybe
it was a mistake.)

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